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:
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.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 :(
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.