I think the 90% rule applies… if we can have a simple solution that covers 90%, rather than a complex one to cover 100%, go with the simple. There are always trade-offs in development - having simple, easy to understand tools always wins out IMO - because greater adoption and usage is key.
> On Sep 7, 2018, at 8:10 AM, Ian Lance Taylor <i...@golang.org> wrote: > > On Thu, Sep 6, 2018 at 4:29 PM, Axel Wagner > <axel.wagner...@googlemail.com> wrote: >> >> The other day I had a lengthy conversation with Rog Peppe, David Crawshaw >> and Nate Finch on twitter and I'd argue that neither of us would really >> count as a Go-novice and we *still* weren't always clear what types certain >> contracts allowed and excluded. > > This does surprise me. I'm certainly too close to the problem, but to > me it always seems quite clear which type arguments a contract allows > and excludes. It's exactly the set of types that type check > successfully. It's true that sometimes this can be a surprising type, > but to me that seems just like the fact that it can be surprising > which types implement an interface. > > What I agree is less clear is which generic function bodies are > permitted by a given contract. That requires more thought. > > 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.
