Skip to content

Conversation

@Soumik15630
Copy link
Contributor

Fixes #4123.

Problem

The formatter specialization for container adaptors (like std::stack, std::queue, std::priority_queue) was overly aggressive. It matched any type with a container_type member alias, causing ambiguous partial specializations when someone tried to define a custom formatter for their own types that happened to have a container_type.

Solution

added a fmt::is_container_adaptor<T> trait. This defaults to std::true_type but allows users to specialize it to std::false_type for their custom types. This removes the library's adaptor formatter from the overload set via SFINAE, resolving the ambiguity and allowing custom formatters to work.

Verification

Added a regression test in test/ranges-test.cc (container_adaptor_partial_specialization) to test the fix and all

thanks .. please let me know if anything need to be changed

@Soumik15630 Soumik15630 force-pushed the fix-range-suppresor-formatter branch from db94827 to 20e213d Compare January 22, 2026 06:58
@Soumik15630 Soumik15630 force-pushed the fix-range-suppresor-formatter branch 4 times, most recently from 4a3a37e to d9c2339 Compare January 22, 2026 07:26
@Soumik15630 Soumik15630 force-pushed the fix-range-suppresor-formatter branch from d9c2339 to d149787 Compare January 22, 2026 07:29
@Soumik15630
Copy link
Contributor Author

Soumik15630 commented Jan 22, 2026

@vitaut Tried to fix the problem, check once and please let me know if I need to update anything
Thanks ..

@Soumik15630
Copy link
Contributor Author

Ping!
Friendly ping — this PR has all ci checks passed.
Let me know if there’s anything else needed.
Thanks 👍

Copy link
Contributor

@vitaut vitaut left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR! I don't think we should introduce another trait for this. Have you tried applying the suggestion from #4123 (comment)?

@Soumik15630
Copy link
Contributor Author

Soumik15630 commented Jan 26, 2026

Thanks for the PR! I don't think we should introduce another trait for this. Have you tried applying the suggestion from #4123 (comment)?

I considered the approach from #4123, but it would disable formatting for standard adaptors like std::stack, std::queue, and std::priority_queue.
These types are not ranges and resolve to range_format::disabled, so checking != disabled would incorrectly exclude them. The current == disabled logic is what allows the adaptor formatter to trigger correctly.

I introduced the is_container_adaptor trait to distinguish between "standard adaptors (which are disabled ranges)" and "user types that explicit opt-out via is_range specialization."

Let me know if I missed something or if you'd like me to proceed differently!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Cannot suppress range formatter when type has a container_type member type.

2 participants