pon., 22 sie 2022 o 04:55 Zhihao Yuan via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
> On Sunday, August 21st, 2022 at 7:13 PM, Jason McKesson via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> >
>
> > protocol/generic [...] it has a "generic header" just like a template
> > function has a template header. Why is the generic version more
> > "normal"?
> >
>
> > The OP seems to think that "normal code" means "I modify objects only
> > by using object.function() calling conventions on them". If that's the
> > primary problem, then I would call this a PEBKAC problem. That is, we
> > should stop trying to believe that all operations on an object should
> > be member functions. That way leads to Java's nonsense.
> >
>
>
> That's actually a problem Bjarne wanted
> to address with his original "unified
> call syntax" paper, and
>
> > It's OK to have non-member functions that are conceptually a part of
> > the class's interface.
>
> like you said, we love non-member calls
> and that his paper only allows
> overwriting f(x) into x.f() since P0251.
> But it doesn't change the fact doing so
> creates an open-ended class interface,
> and that's the exact reason why it was
> dropped.

With some boilerplate this is possible now:
```
template<typename T>
auto my_f(T i) require require (T t) { f(t); }
{
    return f(i);
}
template<typename T>
auto my_f(T i) require require (T t) { t.f(); }
{
    return i.f();
}
```
it needs more code to work with all possible cases (like when both
versions are valid code).
Some helper macro and you can simplify it to:
```
CREATE_WRAPPERS(my_f, f);
```

Functions like this work too as poorman's concept mappings.


>
> Here is an opportunity to bring back
> the beloved f(x) with generics, because
> by naming an entity "String," we place
> a boundary outside a class. Then,
>
> generic<String S>
> void function(S s) {
> /* ... */
> }
>
> inside the function body, we have
> the knowledge that you are operating
> an object that is bounded by String,
> therefore it's intuitive to allow
> starts_with(s, sth) to lookup
> s.starts_with(sth).
>
> --
> 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