On Thu, Sep 6, 2018 at 11:40 AM, Matt Sherman <mwsher...@gmail.com> wrote: > > Perhaps a compromise position would be that these type > groups/classes/contracts are not language builtins but in the stdlib? > contracts.Comparable, etc.
Yes, definitely. > And, for a first implementation, only the stdlib can define contracts. We > might find that to be ‘good enough’ (a positive outcome). Personally I'm very reluctant to limit any language features to the standard library. That effectively makes some packages defined by the language, like the "unsafe" package. I think we should minimize the number of such packages. > 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. Well, I think we do still need contracts for methods. Though I concede that it may be possible to handle those through parameterized interface types. Something like the convert example in the design draft would still need contracts that are unlikely to be defined in the standard library. 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.
