On 16 April 2025 18:08:04 BST, Jason McKesson via Std-Proposals <std-proposals_at_[hidden]> wrote:
>On Wed, Apr 16, 2025 at 5:15 AM Frederick Virchanza Gotham via
>Std-Proposals <std-proposals_at_[hidden]> wrote:
>>
>> On Tue, Apr 15, 2025 at 5:41 PM Jason McKesson wrote:
>> >
>> > If you want your concept to be extensible, for types to explicitly
>> > opt-in, you can.
>>
>> I think you're talking about tags.
>
>No, I'm talking about any mechanism that allows you to add some
>declaration/definition (either in the class or outside of it) which
>your concept detects in order for the concept to evaluate to true.
>This can be done through a traits class, a general template
>declaration that you specialize, a tag inside of the class, or any
>number of other things.
>
>The exact mechanism is outside of the scope of this discussion. What
>matters is that there are ways to allow your concept to be opt-in.
>This is important for concept requirements that are easy to fulfill
>syntactically without fulfilling them *semantically*.
>`contiguous_iterator` being one example; you need to provide a
>`std::to_address` specialization for your iterator type in order for
>it to fulfill that concept.

I think the contiguous_iterator_tag is the opt-in. You have to_address by just having operator->, so most iterators, not just random_access.

>This is useful in general (so you can get
>the pointer to an end iterator), but it also creates a detectable
>difference between a random access iterator and a contiguous iterator.
>
>Put simply, you can get what you want with the language as it stands,
>if you write your concept to allow that. Forcing a type to conform to
>a concept by changing the concept itself is a terrible means to
>accomplish this end.
>--
>Std-Proposals mailing list
>Std-Proposals_at_[hidden]
>https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals