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. (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