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.

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.
_______________________________________________