News for hackers. Stuff that matters.
Re:Go 2 Draft Designs by teolandon on Tuesday August 28, 2018 @12:51PM (#17860434)
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.

Re:Go 2 Draft Designs by platinumrad on Tuesday August 28, 2018 @02:05PM (#17861191)
<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

Re:Go 2 Draft Designs by edflsafoiewq on Tuesday August 28, 2018 @04:31PM (#17862579)
[T] has precedents (Eiffel comes to mind).
Re:Go 2 Draft Designs by ianlancetaylor on Wednesday August 29, 2018 @03:20PM (#17870923)
Unfortunately [T] is also ambiguous with the current Go syntax. The parser can't distinguish an array declaration from a generic type.
Re:Go 2 Draft Designs by alecthomas on Thursday August 30, 2018 @06:11AM (#17875465)
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.
Re:Go 2 Draft Designs by kbd on Tuesday August 28, 2018 @10:17PM (#17864889)
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 :(