On Thu, Sep 6, 2018 at 8:20 AM, <alan.f...@gmail.com> 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.
