On Sat, Aug 20, 2022 at 7:18 AM Михаил Найденов via Std-Proposals
<std-proposals_at_[hidden]> wrote:
> On Sat, Aug 20, 2022 at 1:29 PM Marcin Jaczewski via Std-Proposals <std-proposals_at_[hidden]> wrote:
>> sob., 20 sie 2022 o 06:36 Zhihao Yuan via Std-Proposals
>> <std-proposals_at_[hidden]> napisał(a):
>> >
>> > On Friday, August 19th, 2022 at 12:27 PM, Jason McKesson via Std-Proposals <std-proposals_at_[hidden]> wrote:
>> >...
>> >
>>
>> Is this simply "C++0x concept maps"?
>> Initially Bjarne Stroustrup like to have option to map diffrent type
>> "shapes" to one using concepts,
>> but it was too complex and was strip down to current basic version.
>>
>> Best would be to see what was the most problematic part of this
>> proposal. It could be possible that simply
>> scope of C++0x concepts was a problem not what Bjarne initially proposed.
>>
>> Maybe we should reanimate this old version and try to push it again
>> through the committee.
>
>
> Sadly, this will not cut it at this point - we will need "a different kind of concept" on the function definition itself.
> Currently concepts are just there to constrain the types, passed to the function. The function itself (the body) does not "use" the concept (experts should correct me if I am wrong)
> This allows code like this to be perfectly fine:
>
> template<class T> concept String = requires(T s, std::string val) { {s.contains(val)} -> std::same_as<bool>; }; template<String S> void func(S s) { if(s.contains("hello")) s.clear(); }
>
> Note, we can call clear though we don't require it.
>
> In the protocols/generics model "the concept" is an entity by itself, much like Zhihao said. Inside func, the code will actually ask String itself for methods, not directly the class that it is instantiated with.

That ship sailed when C++20 standardized a concept model that was
fundamentally incapable of definition checking. C++20 concepts are
exactly and only a way to constrain a template declaration, nothing
more. And there's no simple way to turn them into something more.