Contracts are a brilliant solution to the problem on an intellectual level. I really am impressed by how deftly they tackle the stated problem. But I am concerned about their usability on the practical level. The idea is simple but its user interface is not. I don't buy the claim that it's okay because a priest-class will be the only ones writing generic code. Everyone will still have to read it and deal with it.
Scaling back the problem to simply not include operators and fields at all looks like it eliminates so much of the complexity in the implementation and its user interface. Any such limited solution increases the boilerplate of using generics when operators and fields come in to play, certainly, but I think the majority of use-cases for generics are going to be data structures and algorithms more generally expressible without operators anyway (few types have a < operator but any type can have a Less method and without type classes in the haskell/etc. there still isn't a way to handle both without accepting a Less method and requiring a wrapper for types that have a < operator). Is it really *necessary* for generics to support operators and fields? On Thu, Sep 6, 2018 at 9:54 AM Ian Lance Taylor <i...@golang.org> wrote: > > 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. -- 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.
