Hacker News Reader

Comment by teolandon | Hacker News Reader

I do like the idea of contracts for generics, seems to fit in well with Go's interfaces and whole design.

What I do not like at all is that type arguments are put in parens, same as normal arguments. Something like Java's <T> would be more readable IMO. I have to do a double-take to realize that the first paren is for the type arguments. Combine that with the parens that are used for receivers and multiple return values, and function signatures become paren hell.

View on HN

<T> has issues with ambiguous parsing as < and > are also the less than and greater than operators. Rust recently had an small issue with this:

https://github.com/rust-lang/rust/pull/53562

[T] has precedents (Eiffel comes to mind).

I'm always so happy to see Eiffel mentioned. I read Object Oriented Software Construction immediately before I read the book on (then recently-released) Java 1.2, and it made it so clear how much Java got wrong :(

Unfortunately [T] is also ambiguous with the current Go syntax. The parser can't distinguish an array declaration from a generic type.

How about the following:

  contract Addable(t T) {
  	t + t
  }

  func Sum.<T Addable>(x []T) T {
	var total T
	for _, v := range x {
		total += v
	}
	return total
  }

It has the nice property that it's somewhat analogous to type conversions, the grammar should be unambiguous, and it's much less visually confusing than re-using parentheses IMO.

Reply on news.ycombinator.com