On Sun, Aug 21, 2022 at 3:11 AM Zhihao Yuan via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> On Saturday, August 20th, 2022 at 10:04 PM, Sebastian Wittmeier <wittmeier_at_[hidden]> wrote:
>
> isn't the aim (or one of it) of generic programming to use function templates as a function and especially class templates as a class?
>
> Alexander Stepanov, the person who coined
> the term "generic programming," has
> emphasized many times: generic programming
> is not about how to use templates. The first
> version of STL is done in Scheme. Generic
> programming is an idea, templates is only a
> way to approach this idea.
>
>
>
> You say, a "protocol" is a function in a truer sense than a template function. In what ways and where is this useful?
>
>
> The top of the thread pointed out that a
> function template, given the recent efforts
> of improvements, still does not look like
> normal code. A function that takes type
> parameter declared with a protocol not only
> looks like "normal code," it has to look like
> normal code. It can also support separate
> compilation, in other words, builds like
> normal code.

Ignoring the veracity of the whole "templates still don't look like
'normal code'" thing, I take issue with the idea that your
protocol/generic thing looks any more like "normal code" than
templates do. I mean, 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.

It's OK to have non-member functions that are conceptually a part of
the class's interface.