On Sat, 4 Apr 2026 at 00:42, Barry Revzin <barry.revzin_at_[hidden]> wrote:

>
>
> On Fri, Apr 3, 2026 at 1:49 PM Emanuel Spiridon via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> I submitted the paper regarding this proposal, which can be read here:
>> https://isocpp.org/files/papers/P4174R0.pdf
>>
>> I submitted it in time for the June 8th through 13th meetings in Brno,
>> the last concern I have is that I can't go to Brno in person, and I also
>> don't know anyone that can go in my place, while also understanding the
>> concept of this proposal and its flaws.
>>
>> However, if someone on the mailing list is familiar with the core concept
>> of the paper, is able to travel to Brno and attend the meeting, and could
>> possibly have more questions about the proposal, then please contact me.
>>
>
> I don't understand what's being proposed here.
>
> The paper is proposing three additions:
>
>
> - type_tag_list, which is not mentioned anywhere else
>
> type_tag_list<Args...> is a compile time type set, used to store types
under a name;

>
> - merge_tags_and_types_t, which is used in two places but not
> explained, and
>
> merge_tags_and_types_t<Args...> merges each template parameter into one
type_tag_list, if a type_tag_list is an argument, then the contents of it
will be added separately, and at the end, the duplicate types are removed;

>
> - tag_contains, which is not mentioned anywhere else either.
>
> tag_contains<List, T> receives a type_tag_list and a type, and returns
true if the type_tag_list contains the mentioned type

>
> Can you clarify what specifically you are proposing?
>
I am proposing an easier and more readable way of creating concept
constraints.

>
> Barry
>