On Mon, Aug 22, 2022 at 5:14 AM Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:

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

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
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

[image: width=]
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Няма
вирусиwww.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>