Date: Wed, 16 Apr 2025 13:08:04 -0400
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. 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 <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. 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.
Received on 2025-04-16 17:08:17