Well, I can't speak for the other simpler proposals but for my own there's very little to learn - just six built-ins where it's pretty obvious what they mean from their names and the rest is (in effect) just checking that a type satisfies a certain interface or, if it's a struct, has certain fields. If this can't express what you need, then you can't do it.
There was only one example in the draft design and overview papers which it couldn't cope with - the one which required the type to be either a string or a byte slice. All the rest could be dealt with as easily or more easily. Having read all your past papers, I realize of course how long you've been working on this and wouldn't have come up now with the design you have if you didn't believe it was the best one for taking generics forward. So I really hope you can get the draft design to work since I, for one, would love to have generics even if the constraint system is more complicated than I would like. If you can't get it to work, then a simpler design would still be comprehensive enough for many of us. Alan On Friday, September 14, 2018 at 9:24:20 PM UTC+1, Ian Lance Taylor wrote: > > On Fri, Sep 14, 2018 at 10:47 AM, <alan...@gmail.com <javascript:>> > wrote: > > > > The problem is that many people think the current draft design is too > > complex and I haven't seen a plausible suggestion from anyone (myself > > included) which would be appreciably simpler but as comprehensive, or > nearly > > so. > > > > This is why I'd concluded that, if a system could be devised which was > > simple but nonetheless addressed 90% of the use cases for generics, it > might > > be good enough. > > We've been working on this for years. It's far too soon to give up on > a reasonably complete solution. > > And, as I tried to say earlier, a 90% solution has its own > complexities. If the only reason to reject the design draft is > complexity, then it's not obvious that a 90% solution is really > simpler. > > And, of course, we're only really going to understand the complexity > of the design draft when we can try writing real code that uses it. > > 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. For more options, visit https://groups.google.com/d/optout.
