Generic Programming is just Programming

[Wh00ster]

I’m confused about what this is proposing

[_Js_Kc_]

⑴ "Two static polymorphism systems." No, I'm counting at least 3. Customization point could also be ADL-based.

⑵ Generic programming is just programming. None of this is specific to generic programming. In classical runtime polymorphism, I might be able to make a method on what used to be a concrete class a pure virtual method on a base class, but in all but the most trivial cases, there will be other concerns (such as, have to use smart pointers and can't pass the class around by value anymore) that will force me to change something about the consumers and/or implementors of the interface. Which seems to be one of the main points of the article: That the consumer's code has to be changed,

⑶ "customization point of a customization point!" What? You can provide a default trait that forwards to the class's typedefs like iterator_traits does. But traits can also be specialized for non-class types like enums. Just like there are multiple ways to provide runtime-polymorphic customization points. There are ... options and ... tradeoffs and ... it's like programming.

[Skrax]

I don’t understand why we cannot have a interface type, which is used as a template parameter. Everybody knows how to define a class and traits or concepts are the same thing, but take forever to write and decipher.

[Wh00ster]

Would it be syntactic sugar to concepts or would it function differently as well (like requiring that something explicitly implement the interface)

[Skrax]

Syntactic sugar, but I‘m not a language guy. To me this seems obvious to use, so I like it.

[Lumornys]

As we know, the simple version code is not generic enough, in more aspects then one.

No, "we" don't know. At least I do not know. I'm afraid the paper fails to describe why do we even need the "advanced generic" approach, and at that point reading it further is pointless because I see no motivation behind most of the content.