On Fri, Sep 7, 2018 at 6: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
I think the major problem is that all the operations depend on their
context . Individually they can mean many different things.
It's very easy to know what a[0] means given the context that a is a
slice but contracts take the context away. That could be a slice or a
map with an integral key type.
To describe a sufficiently-tight contract you need to be able to come
up with an elaborate conjunction of properties that allow everything
needed while disallowing everything that would cause your code to
break. To read such a contract, you need to be able to know all the
rules involved and to be able to run the solver in your head that
says: okay X, Y, Z can do A. X and Y can do B. And Y and Z can do C.
Ah, so it must be Y.
Maybe it would be easier if there were a way to specify negative
requirements like
a[0] but not a["s"]
so it would be easier to express and understand what you cannot do.
That of course introduces even more complexity, though.
In the generics thread, we were talking about embedding type arguments
and what would happen if you embedded a regular type and a type
argument. If that's allowed that would cause issues when a selector in
the type argument and the regular type collided so the contract would
need to be
struct{ io.Reader; T}{}.Read
To express that T cannot have a Read selector. That's a somewhat
subtle contract to write and to read. Once you know what it means and
memorize the pattern it's clear, but it would be a hard ask to wake
someone up in the middle of the night who's never seen it and have
them explain the implications.
Any contract that's more than a few lines is going to need a large
comment explaining what is and is not allowed by the contract. While
you have to do that with properties of values inexpressible in the
type system anyway but I don't think you should have to do that for
what should amount to "any unsigned integral type".
--
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.
