Thanks Ian, was hoping you’d weigh in. Perhaps a compromise position would be that these type groups/classes/contracts are not language builtins but in the stdlib? contracts.Comparable, etc. If we really don’t want to see the dot, we import with _.
And, for a first implementation, only the stdlib can define contracts. We might find that to be ‘good enough’ (a positive outcome). The hypothesis (just to reiterate) is that there is a small number of contracts that cover the majority of use cases, and so we can exploit that fact to minimize new language concepts. 80% benefit for 20% complexity, which is how I describe Go’s current type system. On Thursday, September 6, 2018 at 12:54:24 PM UTC-4, Ian Lance Taylor wrote: > > On Thu, Sep 6, 2018 at 8:20 AM, <alan...@gmail.com <javascript:>> wrote: > > > > As I wasn't happy with some aspects of it, I've rewritten my feedback on > the > > Go 2 Generics draft and deleted the original gist. Here's the link to > the > > new gist for anybody who's interested: > > https://gist.github.com/alanfo/5da5932c7b60fd130a928ebbace1f251 > > > > This is still based on the type-class idea though I'm now proposing a > > simplified contracts approach to go with it rather than trying to make > > interfaces fit. It seems to deal easily now with all the examples in the > > draft paper though no doubt there will be stuff that it can't do or that > > I've overlooked. > > Thanks for writing this. I never got around to reading the earlier > feedback. And thanks for working out the examples. > > Personally I think an important feature of the current design draft is > that it adds relatively few new concepts to the language. While > concepts are of course a new feature, a contract looks like a > function. If you can read a function, you can read a contract. You > don't need to understand a new set of ideas to know what a contract > is. With your proposal, everybody has to learn a new set of > predeclared identifiers. You list 14 new ones, including $struct. I > count 39 existing predeclared identifiers, so this is a significant > increase. Also, of course, the new identifiers don't look like any > existing ones, with the $, but perhaps that could be changed. I would > very much prefer to not add so many new names. > > If new features are added to the language, your approach may require > new predeclared identifiers, whereas the contract approach will > automatically adjust. > > It's worth noting that your suggestion is less powerful than the > design draft, in that you can't express the notion of type parameter > that must be a channel type or a slice type. This may not matter very > much, because the generic function can always write chan T or []T. > > > > It looks to me as though, if it requires a contract at all, you might > end up writing one from scratch for most generic functions/types you need. > Even if the commoner ones could be included in a 'contracts' package in the > standard library, you'd still need to import that package and then write > stuff like 'contracts.Comparable' which is a bit verbose. > > > > Even if the present design prove workable, I think writing contracts may > prove a bit of a black art and that, if things are at all complicated, some > programmers may just give it up and embed the function's code in the > contract which defeats the object of having them in the first place! > > I believe we can use tooling to make these operations easier. For > example, assuming we can make contracts work at all, it should be > straightforward to write a tool that can minimize a contract given an > existing contract definition, and therefore can produce a minimal > contract for an existing function body. > > Note that while I think it's important that there be some way to > express complex contracts, I think they will be used quite rarely. > > > > The more I look at this, the more complicated it seems to get :( > > Yes. > > 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.
