C++ Logo


Advanced search

Re: [std-proposals] Generic code, not the API you are looking for

From: Zhihao Yuan <zy_at_[hidden]>
Date: Mon, 22 Aug 2022 02:55:03 +0000
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

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

Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.

Received on 2022-08-22 02:55:16