On Mon, Aug 22, 2022 at 5:14 AM Jason McKesson via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
On Sun, Aug 21, 2022 at 3:11 AM Zhihao Yuan via Std-Proposals
<std-proposals@lists.isocpp.org> wrote:
> On Saturday, August 20th, 2022 at 10:04 PM, Sebastian Wittmeier <wittmeier@projectalpha.org> 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
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.

Ideally the style should be up to the algorithm developer, 
and moving to a generic form should not force a different style. 
But as we all know, having free functions does not make things easier or more clean just... possible.

The main issue I see is that little people will go the extra mile. I can't imagine having to first invent all the extra machinery (traits, CPO, whatnot), 
then rework the code you already have, just to make it "SUPER generic". One will have to plan in advance and commit to it, leaving all this to library authors more or less. 

For the general audience "just make the type a template argument" will be the no-brainer and the vast majority of code will simply stay there.
The "right" genetic code is currently in severe disadvantage. 
Std-Proposals mailing list

 width=Няма вирусиwww.avast.com