As many others have said, a lot of thought has obviously gone into the Go 2 draft design for generics and, personally, I'm very happy with the basic syntax both at the declaration and call sites. However, I'm far less happy about the use of 'contracts', as currently envisaged, to constrain the types which can be used to instantiate a generic function or type. This is because:
-
Contracts seem a rather amorphous concept and it is not at all clear to me how the compiler is going to check that a contract is sufficient to satisfy what the function/type is doing in all circumstances. If a very complex algorithm is required, then this is going to slow down compilation.
-
There seems to be too many problem cases for comfort. Dealing with untyped numeric constants looks to be a particularly unintuitive area and not being able to fully determine method signatures (without casting to an interface) or to distinguish value receivers (without