I somewhat disagree. FTA: “If the callsite is some_function(2);, the compiler resolves T as i32 and selects the corresponding branch, returning the value incremented by one. […] The important point is that the decision is driven entirely by type information, not by runtime inspection”

Given that, this isn’t that different from C generics (https://en.cppreference.com/w/c/language/generic.html), and people call that generics, too.

Having said that, even ignoring that this requires all implementations to be in a single source file (yes, you probably could use m4 or #include or whatever it’s called in this language) I do not find this syntax elegant.

Also, one thing that it doesn’t seem to support is generating compiler errors when calling a function with a type that isn’t supported.

▲

noelwelsh 2 hours ago | parent | next [-]

The key concept in "parametric polymorphism", which is what programming language nerds mean by generics, is "parametricity" [1]. This is basically the idea that all calls to a generic function should act in the same way regardless of the type of the actual concrete calls. The very first example breaks parametricity, as it multiplies for float, adds for i32, and isn't defined for other types.

It's implementation has the same issues as generics in Zig, which is also not parametric.

It's ok to explore other points in the design space, but the language designer should be aware of what they're doing and the tradeoffs involved. In the case of adhoc (non-parametric) polymorphism, there is a lot of work on type classes to draw on.

[1]: https://en.wikipedia.org/wiki/Parametricity

	▲	Someone 2 hours ago \| parent [-]
		I don’t see how that Wikipedia page supports your claim “The key concept in "parametric polymorphism", which is what programming language nerds mean by generics, is "parametricity"”. That page doesn’t even contain the character sequence “generic”. IMO, https://en.wikipedia.org/wiki/Generic_programming is more appropriate. It talks of “data types to-be-specified-later”, something that this and C generic lack. That’s one of the reasons that I wrote “I _somewhat_ disagree”. Also, I don’t see how one would define “act in the same way”. A function that fully acts in the same way regardless of the types of its arguments cannot do much with its arguments. For example, a function “/” doesn’t act in exactly the same way on floats and integers in many languages (5.0/2.0 may return 2,5 while 5/2 returns 2; if you say it should return 2,5 instead you’re having a function from T×T to T for floats but a function from T×T to U for ints; why would you call that “act in the same way”?), “+” may or may not wrap around depending on actual type, etc.

▲

jadedtuna 2 hours ago | parent | prev [-]

Right, but C-style generics really are not generics at all. As other comments point out, they effectively are conpile-time if statements. A generic function would automatically instantiate and generate required code for different call types, and perform the correct operations. The C-style "generics" are a conpile-time switch statement, switching on types.