On Mon, Aug 17, 2020 at 10:13 AM Jonathan Gerber <jlger...@gmail.com> wrote: > > 1) Of the enumerated omissions, the ones that I think are really unfortunate > are, in order of importance, from my perspective: > > No operator methods & no adapters - Doesn't this make generic types sort of > second class?. I think these features would be an elegant addition to the > language but I assume that there is a reason for their omission.
To me this is kind of separate from generics. It's true that the lack of operator methods means that user defined types are never as capable as the types predefined by the language. But that limitation seems to apply to all types, not just generic types. > No support covariance or contravariance. Maybe I am on shaky ground in terms > of my understanding but doesn't this mean, for instance, that if I have two > interfaces, Foo and Bar, and a third composite interface, FooBar, which > consists of Foo and Bar, that a function with a generic parameter T > constrained by Foo would not accept a type that implements FooBar? If i am > incorrect, where does this come into play? Go in general does not support covariance and contravariance because those are complex concepts and Go has a very simple type system. https://golang.org/doc/faq#covariant_types . That said, I don't think that your example uses covariance. If FooBar is composed of Foo and Bar (type FooBar interface { Foo; Bar }) then any type that implements FooBar also implements Foo. > No support for variadic type parameters. Rust gets around this with hygienic > macros and meta-programming. I am not a big fan of the level of > complexity/quirkiness involved with working around the lack of variadics in > Rust. I hope to see them in Generics in Go one day. Otherwise, you will > probably end up api bloat full of functions differing only in the number of > parameters supported. We may get variadic type parameters some day, if we can figure out a way to make them work. I don't think that's a priority for the first version, though. And it's not easy to see how to make them work; their support in C++ seems to rely heavily on SFINAE, which I don't think we particularly we want in Go. > 2) I don't see syntax for directly applying multiple constraints to a generic > type. Is this achievable only via interface composition? Yes. > 3) And something I glossed over during the first reading, but is a bit sad - > Methods may not take additional type arguments. Yes. I think we'd all like them if we can figure out how to implement them, but it's not obvious. See the example at https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#No-parameterized-methods . > Also, in the area of ergonomics, here are some thoughts: > 1) Allow for separating out generic type declarations from constraints. Rust > allows you to split type parameter declaration from type constraints via an > optional `where` keyword which comes right before the body of the entity. > This is very helpful for readability, especially given complex constraints. The current design draft lets you move complex constraints into their own separately defined type, so I don't see a clear need for further separation. > 2) I personally don't think allowing multiple types to share a constraint is > worth not allowing unbounded types without the bulky "interface{}" type. Is > there some other simpler syntax that could be considered? Would a simple {} > be a parsing nightmare? What about '_' ? Something like `func Something > (type T _, U SuperUseful ) (a T, b U){...}` ? Most likely we would support using "any" as an alias for "interface{}". Thanks for the note. Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXjHwq%3Dep0uD%2BYvntLmETfJFEJ9MytJrW7Egvs5tkT2mw%40mail.gmail.com.
