4 ms·
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
by teolandon 8y ago
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.
- platinumrad 8y ago<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 https://github.com/rust-lang/rust/pull/53562
- edflsafoiewq 8y ago[T] has precedents (Eiffel comes to mind).
- kbd 8y agoI'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 :(
- ianlancetaylor 8y agoUnfortunately [T] is also ambiguous with the current Go syntax. The parser can't distinguish an array declaration from a generic type.
- alecthomas 8y agoHow 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.