On Tue, Apr 15, 2025 at 5:02 AM Frederick Virchanza Gotham via
Std-Proposals <std-proposals_at_[hidden]> wrote:
>
>
>
> On Tuesday, April 15, 2025, Jason McKesson wrote:
>>
>>
>> There's a reason concepts are the only kind of template that can't be
>> specialized. It is *very* important to the integrity of the concepts
>> system that there's a single, fixed definition against which all
>> constrained templates can be tested. `concept_name<type>` should have
>> exactly and only one answer, and that answer must be the same
>> everywhere.
>
>
>
> You would never get a "bad answer" though.
>
> Translation units that don't include "HugeInt.hpp" won't ever make reference to the class 'HugeInt', and therefore it doesn't matter if the concept allows for HugeInt in some translation units but not in others.

You know how if you define a class in one TU, and then define the same
class in another TU, the standard is OK with that so long as both
definitions are identical? And if they're not, it's ill-formed, NDR?

Concepts are like that.

You don't get to take an existing type and make it do something else
by changing its definition. You can change things external to that
definition. But the type is precisely what the original writer said it
is, and you don't get to touch it without touching its definition.
Concepts are the same way.

If you want your concept to be extensible, for types to explicitly
opt-in, you can. And that can be good or important, depending on a
variety of factors. Just as you can make types which are extensible
(derived classes and virtual interfaces, template parameters, etc).

But those extension mechanisms are always opt-in: the writer must
*choose* to use them.