Date: Mon, 25 May 2026 14:44:31 -0700
Thanks for the feedback, everyone.
With the exception of std::flat_*, the other container adapters (stack,
queue, and priority_queue) define their value_type, reference, and
const_reference in terms of the underlying container, so they just work
with vector<bool>. See example:
https://eel.is/c++draft/priority.queue#priqueue.overview-1
I like Arthur's proposal to do the same for std::flat_*. I'll start a draft.
On Mon, May 25, 2026 at 7:53 AM Yongwei Wu via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> On Mon, 25 May 2026 at 12:08, Hewill Kang via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>>
>>> FWIW, I found it super easy to implement a proper `flat_map` that Just
>>> Works for all types (even bool). I've been "shipping" it in my P1144 fork
>>> of libc++ since at least January 2023, since before Hui Xie's flat
>>> containers were merged to Clang trunk.
>>> https://godbolt.org/z/j1az7vY87
>>> These days the patch is reduced to just a few lines on top of Hui's
>>> implementation:
>>>
>>> https://github.com/llvm/llvm-project/commit/a3cb6f367fe50ac40cefc6bced487e141f6cbe23
>>>
>>> I certainly think that all vendors (yes, even libc++!) should ship an
>>> implementation of `flat_set` and `flat_map` that Just Works, even with
>>> `bool`. I think libc++'s current behavior is deplorable.
>>>
>>
> I think libc++'s behaviour is OK, given the current wording of the
> standard.
>
>
>> Does that mean we need to change the wording of the paper standard? Well,
>>> IMHO, vendors *should* know to Do The Right Thing regardless of whether
>>> the paper standard requires it. But changing the paper standard would
>>> probably help in practice, so sure, I'd encourage you to go for it.
>>>
>>
> Do the right thing, if the right thing does not go against the standard.
> Otherwise we should change the standard first.
>
> The trick with the paper standard is that `vector<bool>` isn't a "sequence
>>> container"; so either you'll have to figure out how to stretch the
>>> definition of "sequence container" to include `vector<bool>`, or you'll
>>> have to extend the definition of `flat_set` to include `vector<bool>` as a
>>> special case. The former would be more generally useful in the future, but
>>> the latter is way easier.
>>>
>>
> I think Aryan's approach is good and simple. Also, I won't worry about
> `flat_set<bool>`. Only `flat_map<Key, bool>` is likely, though, honestly
> speaking, it can be replaced with `flat_set<Key>` too...
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
With the exception of std::flat_*, the other container adapters (stack,
queue, and priority_queue) define their value_type, reference, and
const_reference in terms of the underlying container, so they just work
with vector<bool>. See example:
https://eel.is/c++draft/priority.queue#priqueue.overview-1
I like Arthur's proposal to do the same for std::flat_*. I'll start a draft.
On Mon, May 25, 2026 at 7:53 AM Yongwei Wu via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> On Mon, 25 May 2026 at 12:08, Hewill Kang via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>>
>>> FWIW, I found it super easy to implement a proper `flat_map` that Just
>>> Works for all types (even bool). I've been "shipping" it in my P1144 fork
>>> of libc++ since at least January 2023, since before Hui Xie's flat
>>> containers were merged to Clang trunk.
>>> https://godbolt.org/z/j1az7vY87
>>> These days the patch is reduced to just a few lines on top of Hui's
>>> implementation:
>>>
>>> https://github.com/llvm/llvm-project/commit/a3cb6f367fe50ac40cefc6bced487e141f6cbe23
>>>
>>> I certainly think that all vendors (yes, even libc++!) should ship an
>>> implementation of `flat_set` and `flat_map` that Just Works, even with
>>> `bool`. I think libc++'s current behavior is deplorable.
>>>
>>
> I think libc++'s behaviour is OK, given the current wording of the
> standard.
>
>
>> Does that mean we need to change the wording of the paper standard? Well,
>>> IMHO, vendors *should* know to Do The Right Thing regardless of whether
>>> the paper standard requires it. But changing the paper standard would
>>> probably help in practice, so sure, I'd encourage you to go for it.
>>>
>>
> Do the right thing, if the right thing does not go against the standard.
> Otherwise we should change the standard first.
>
> The trick with the paper standard is that `vector<bool>` isn't a "sequence
>>> container"; so either you'll have to figure out how to stretch the
>>> definition of "sequence container" to include `vector<bool>`, or you'll
>>> have to extend the definition of `flat_set` to include `vector<bool>` as a
>>> special case. The former would be more generally useful in the future, but
>>> the latter is way easier.
>>>
>>
> I think Aryan's approach is good and simple. Also, I won't worry about
> `flat_set<bool>`. Only `flat_map<Key, bool>` is likely, though, honestly
> speaking, it can be replaced with `flat_set<Key>` too...
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2026-05-25 21:44:48
