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@lists.isocpp.org> wrote:
pon., 22 sie 2022 o 04:55 Zhihao Yuan via Std-Proposals
<std-proposals@lists.isocpp.org> napisał(a):
>
> On Sunday, August 21st, 2022 at 7:13 PM, Jason McKesson via Std-Proposals <std-proposals@lists.isocpp.org> 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@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