On Tuesday, August 30th, 2022 at 9:23 AM, Jason McKesson via Std-Proposals std-proposals_at_[hidden] wrote:

> This is one of my biggest problems with your proposal as written. You
> identify a problem, but you don't really put forth an argument that it
> is a problem. You declare that `s.starts_with` is less "awkward to
> use" than `strings::starts_with(s)`, but you don't give any reasons
> for this. You take it as an assumption that your audience thinks that
> free functions are "objectively worse" than member functions.


Extracting words from a paper doesn't
help to understand the paper. Nothing
you said here is true, even the 'You
declare that `s.starts_with(s)` is
less "awkward to use" than
`strings::starts_with(s)`' part.
Here is the relevant section:

> First there is the extra verbosity because we want (need) to be explicit. Then there is the often-awkward use of a free-function call. While these two might be considered “nitpicking”, they are just the visible side of the real issue: The type mapping is moved inside the function body!

The text says "there is the often-awkward
use of a free-function call." It did not say
a free-function call is awkward. What is
verbose, and awkward? Let's look at the
example:

> template<class S>
> void silly(S& s)
> {
> using char_type = strings::traits<S>::char_type; //< verbose, extra, unrelated to the algorithm code
> // ...
> if(strings::starts_with(s, "hello")) //< verbose, extra, unrelated to the algorithm code
> strings::clear(s); //< verbose, extra, unrelated to the algorithm code
> // ...
> }

When we think of free-function, the
intuition is clear(s). What is
strings::clear(s)? It's not truly
free, not as free as an inline friend.
It's a qualified function call in the
hope of establishing an abstraction
boundary. The right comparison of
that is you call

  s.string::clear();

which is, indeed, verbose. Nobody
does that.

But the situation of customization
points is that, you can't live without
s.string::clear(). If someone
accidentally missed one such
qualification, or used some other
qualification such as
string_utils::clear(s),
immediately they lose all the quality
control of this piece of code.
What's the problem? Name lookup?
ADL? Namespace? Corner cases
in concepts? To find the right solution
you have to identify the right problem.
The paper pointed out the problem:
The type mapping is moved inside
the function body.

> Where in the original, non-generic function, no mapping is needed, and in the standard template any functionality mapping is a job for the types themselves, here we inject extra code, unrelated to the algorithm that is implemented, in order to create an extra layer of mapping b/w the types and the required entities.

Exactly.

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