Hi

On Mon, 10 Nov 2025, 15:51 Arthur O'Dwyer via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> On Mon, Nov 10, 2025 at 1:15 AM 叶易安 via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> We notice that we have 2 available 'tags' in C++ standard library now:
>>
>> =====
>> class my_iterator { using iterator_concept =
>> std::random_access_iterator_tag };
>> class my_sender { using sender_concept = std::execution::sender_t; }
>> =====
>>
>> Oops, the first ends with `_tag` and the second ends with `_t`. But they
>> share the same effect (to make a class satisfy a particular concept).
>> Should we unify them?
>> Hmmm, before that let's see where we use `_tag` and `_t` in C++ standard
>> library.
>>
>> xxx_t:
>> 1. <type_traits>. When we have `add_const<T>::type`, we typedef an
>> `add_const_t<T>`.
>> 2. Typedef which unifies different platforms. `uint8_t`, `wchar_t`,
>> `clock_t`, etc.
>> 3. Utility type of global constexpr variable. e.g. nullopt_t,
>> unexpected_t, etc.
>> 4. Utility type of function overload parameters. e.g.
>> unique_lock(defer_lock_t), vector(from_range_t), etc.
>>
>> xxx_tag:
>> 1. Customize xxx_concept in class. e.g. using iterator_concept
>> forward/bidirectional/.../random_access_iterator_tag.
>>
>> Should we rename `std::execution::sender_t` into
>> `std::execution::sender_tag`?
>> Thank you!
>>
>
> Yes, it certainly seems so (at first glance) to me. Like you, I'm not
> aware of any prior art for using `_t` as the suffix for a tag type.
>

Aren't allocator_arg_t, inplace_t, defer_lock_t etc. tag types?

Using a "tag" suffix is unique to the iterator categories, which are from
30 years ago and that design hasn't been repeated elsewhere in the library.


(Although C++20 Coroutines used no suffix at all for theirs, e.g.
> `std::suspend_always`.)
> The tag types `sender_t` and `receiver_t` were introduced in P2300
> <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2300r10.html>.
> I'm cc'ing a couple of the P2300 authors for their thoughts, but yeah,
> unless someone presents a very compelling reason why they're _t instead of
> _tag, I think a new LWG issue should be filed.
>
> Thank you for bringing this up!
> –Arthur
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>