Hi

On Mon, 10 Nov 2025, 15:51 Arthur O'Dwyer via Std-Proposals, <std-proposals@lists.isocpp.org> wrote:
On Mon, Nov 10, 2025 at 1:15 AM 叶易安 via Std-Proposals <std-proposals@lists.isocpp.org> 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.
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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals