On Sun, Sep 9, 2018 at 12:46 AM Ian Lance Taylor <i...@golang.org> wrote:
> To me contracts aren't implicit or roundabout at all, at least not
> when it comes to which types they permit. They are very direct and
> straightforward, and they really could not be simpler. But clearly
> many people disagree. Perhaps we need to make them more complex by
> turning them into a list of explicit constraints.
I realized there's a kind of ambiguity in the conversation here.
There are two cases for what types a fixed contract C allows. Let's
say that F is some generic func over C.
The first is I have this type T, can I call F with it? This case is
easy because you can look at T and C check off each property.
The other is I need to use F so what are the possible T I can
construct. This is where it's less clear what the options are when C
constrains basic types. Operators are overloaded and there a multitude
of special cases for basic types. While this overloading and these
special cases make it simple to use a specific basic type, they make
it hard to work backwards from a list of properties and see what
options are available. Looking at contract stringable(s T) { string(s)
}, it's not immediately obvious that int is admissible.
With interfaces both cases are the same because it's a set of
unambiguous methods.
--
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.
