FWIW, personally I think type parameters are far more important than contracts about the draft design. i.e. I agree, that if you can't make contracts work (or decide they aren't a good solution), I'd still think it's worth considering to only add type-parameters on their own.
To me, contracts only achieve one thing over interface-constrained type-parameters, which is to reduce boilerplate in wrapping operators. IMO most everything else about the design (type-checking different arguments/returns being consistent, writing generic data structures…) can probably be achieved without contracts. Personally, I'd be fine not to use operators when writing generic code (and writing wrapper-methods when using it), if the alternative is not to be able to write type-safe generic code at all. (I know that some people are unhappy about the syntax of type-parameters and I agree. But syntax can be talked about once we know what the semantics are it needs to express) On Thursday, September 6, 2018 at 7:30:02 PM UTC+2, soapboxcicero wrote: > > 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 <ia...@golang.org > <javascript:>> 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...@googlegroups.com <javascript:>. > > 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.
