Hacker News Reader

>1. Maybe change the syntax to this one:

>func eat(food []generic.Type) Or

>func eat(food []g::type) Or something that doesn’t involve adding more <> or ()

I don't understand how this would work with multiple generic parameters. Say I have

func merge(a []g::type, b []g::type) []g::type

How do you specify that a, b and the returned value must have the same type and implement the comparison operators?

Also, why are people trying so hard to stay away from < and >?

“type” here is whatever you want it to be

  func merge(a []g::thing, b []g::thing) []g::otherThing

The <> syntax is well accepted, that’s the only thing it has. What’s annoying is that it adds to the function signature when it’s not necessary.

In other languages, you can easily define constraints on generic types. It’s not rocket science, but actively ignoring any advancement since the 70s means that you have to reinvent the wheel constantly.

Golang could do this by implementing unions on interfaces.

I certainly agree with your later example (cars+planes)...but how do union types help with subtyping?

how do generics help with subtyping?

"or even better: force listing all the types that are currently using this generic"

This is a bad idea. Imagine a generic hash map, we surely want it to work with any value type.

True. I’m trying to find a solution to the biggest problem of generics which is imo that you can’t understand how it’s being used when reading one.

It’s fine if the function doesn’t do much. But if it’s nesting generics, or doing anything complex, then not using a union of interfaces make it really hard to understand code.

I’d like if Golang would add unions of interfaces. But generics? I’m not sure if it’s a good idea.

Or maybe if you import a package that have some generic functions, you would need to add a declaration that list what the types using these generics are.

  Import “stuffWithGeneric{
    thing(K, V) -> (egg, bacon),
    thing(K, V) -> (int, string),
  }”

Imagine you have a non-generic function, for example, `parseJsonData(string)`, how would you understand how it is being used? It can be called with all sorts of input.

Is the problem you are describing different?

That’s true. Usually the name of the argument indicates how it is used. Without it you are lost.

I feel like what really tricks me is this kind of code:

parseJsonData(t T)

Now neither the type nor the argument name help you understanding the purpose of the function.

In this case wouldn't the name of a contract be enough?

Or, perhaps, not enough, but informative to the same degree?

The one-letter "naming convention" used for generic types by most developers is very unfortunate.

Why? There are usually only one or two of them, it's like using `i` for loops instead of `indexOfElement`.

Type parameters are more like function arguments, not loop variables. There is often one or two arguments too but they are not as local (contained) as loop variables.

This is a problem with template metaprogramming, not with generics. Code using generics isn’t less obvious than code using only specialized types. On the contrary: You work with strong typing instead of using interface {} everywhere.

People use interface{} everywhere because union interfaces don’t exist in Golang. If union interfaces were a thing you could be writting

  func thing(a car+plane)

You can substitute all generically typed items with the type interface {}. That's how much is known about the object - basically nothing.

You can substitute generics that conform to a contract by their contract.

I also dislike the use of fun<T>(a:T b:T)->T because it make look weird.

How about:

    fun(a:$T b:$T) -> $T //to look like templating
    fun(a::T b::T) -> ::T //to look like "a type but depper"
    fun(a:_T b:_T) -> _T //to look like "a type hole"

mmm... I like more the third :)

> without... letting people being able to abuse them. C++ cough cough.

Curious what you consider "abuse", given the standard library itself uses generics in all sorts of ways?

For example. Typical C++ code:

  Thing<A<B, C<D>, E>>()

I know the syntax, but what about this is "abuse" of generics exactly?

It makes the code unreadable.

That's not people abusing the syntax, that's the syntax being intertwined with the semantics. Mind you, a similar thing can pop up in a language like C#, it just happens less often.

And? Care to elaborate?

It makes the code unreadable to others.

The population of C++ developers who manage to write and ship code using templates far more complex than that would suggest otherwise.

who said that code is hard to write?

I said it's hard to read.

And it's probably filled with bugs.

If it isn't hard to write, it's easy enough to read to be useful, and understanding the domain and the problem being solved makes reading it even easier. Just about any production code is hard to read.

>And it's probably filled with bugs.

All nontrivial code is probably filled with bugs.

  Thing<A<B, C<D>, E>>

except for a different bracket syntax, it is the type level equivalent of:

  Thing(A(B, C(D)), E)

There absolutely nothing unreadable with that. Mind you, I find <> brackets somewhat ugly, but that's subjective and plenty of languages have made the same choice.

To be more constructive, C++ templates have two major pain points: template specialization means that the template machinery is a full term rewriting engine, so arbitrary computations can be expressed in it. The other issue is that it is hard to specify template constraints (or concepts, it type classes or traits or whatever term you prefer).

A new language can eskew specialization (but note that Rust, that wants to compete in the same space as C++ has added, or is adding them), and there is no good reason not to have constraints in a new language (the design space is well explored).

I think you misplaced a ) there.

  Thing<A<B, C<D>, E>>

Is the type level equivalent of:

  Thing(A(B, C(D), E))

Not:

  Thing(A(B, C(D)), E)

I guess this is illustrative for how it is unreadable.

It is more illustrative that it is inconvenient to type in the HN commento box from mobile.

Seems more like an abuse of one letter names.

Abuse by users is subjective. Still, C++ templates make parsing undecidable.

It's worse than just a Turing-complete preprocessor like, say, Lisp macros. In C++ you cannot decide the type of the next token until you evaluate the (Turing-complete) templates.

This shows that the templates are at least a bit too powerful.