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.


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