Hello again,
I ended up writing a small proposal on this topic as I am quite bothered
with the issue.
Attached is the draft
Thank You

On Tue, Aug 23, 2022 at 1:14 PM Marcin Jaczewski via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>