On Sat, Aug 20, 2022 at 1:29 PM Marcin Jaczewski via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
sob., 20 sie 2022 o 06:36 Zhihao Yuan via Std-Proposals
<std-proposals@lists.isocpp.org> napisał(a):
>
> On Friday, August 19th, 2022 at 12:27 PM, Jason McKesson via Std-Proposals <std-proposals@lists.isocpp.org> 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.


> --
> Zhihao Yuan, ID lichray
> The best way to predict the future is to invent it.
> _______________________________________________--
> Std-Proposals mailing list
> Std-Proposals@lists.isocpp.org
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals