Sorry, the proposed new keyword is 'typecheck' not 'keycheck'. Alan
On Monday, September 10, 2018 at 6:01:12 PM UTC+1, alanfo wrote: > > I've revised my feedback on this topic yet again in the light of > criticisms made by Ian which I thought were justified. > > Briefly, I'm now proposing that there should only be one additional > contextual keyword 'keycheck' though a number of other changes have been > made to fit in with this. > > The link is the same as before but is repeated below for those who are > interested: > https://gist.github.com/alanfo/5da5932c7b60fd130a928ebbace1f251 > > Alan > > On Thursday, September 6, 2018 at 5:54:24 PM UTC+1, Ian Lance Taylor wrote: >> >> On Thu, Sep 6, 2018 at 8:20 AM, <alan...@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 >> <https://www.google.com/url?q=https%3A%2F%2Fgist.github.com%2Falanfo%2F5da5932c7b60fd130a928ebbace1f251&sa=D&sntz=1&usg=AFQjCNGuSGRWugrVbmN5NzB6xf9SunDM8g> >> >> > >> > 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.
