On Fri, Sep 7, 2018 at 3:10 PM Ian Lance Taylor <i...@golang.org> wrote:
> 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.
I yield that it's a bit nit-picky, but I believe we agreed that to not be
*quite* the case. e.g. `[1]int` is not type-checking for the body of
`contract indexable (a T) { a[1] = 42 }`, but the contract will likely
allow it, because you can't enumerate all possible indices.
Similarly, I'm not sure how I'd specify contractually that an integer is
supposed to be signed or unsigned. Naively, I could require signedness by
`i = -1` and maybe unsignedness by `i = 1 << (8*unsafe.Sizeof(i)-1)`, I
guess (though requiring unsafe, ugh)? But that would also, in a way, back
to the array-case: If we would allow those contracts, then `i << 1`
wouldn't allow to shift by more than 1, but if we'd do `i << 63`, then
anything below a uint64 isn't allowed. So, just as with arrays, we seem to
have to disable the "constant overflows" check in contracts. But then… I
can't figure out a way to require an integer to be un/signed.
It's a bit nit-picky to paint this as too much of a problem, because
neither of these is *terribly* likely to be an issue in practice? But at
the same time, I'm *still* constantly learning new things about Go, even
after 5 years. So if I'm finding this many things I find surprising or
confusing about contracts in a couple days, I just kind of fear what I'll
discover about them over the coming years :)
(and for what it's worth, when I first heard about them, I found the
solution pretty elegant. I mean, I would've brought up these things if I
would have thought about them at the time :) )
t'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.
>
ISTM that these cases are pretty straight forward to enumerate: For a type
to satisfy an interface, all methods in that interface either a) are
declared with that type as a receiver or b) are promoted by an embedded
struct field. I guess there could be some confusion around unexported
identifiers?
I don't know, obviously this is a subjective question and it's hard to
argue what's confusing and what isn't. But what am I missing about
interfaces here? Compared to contracts, that seems pretty straight forward.
What I agree is less clear is which generic function bodies are
> permitted by a given contract. That requires more thought.
>
Okay, I promise I will not say another thing here for a while, because I do
totally agree that there's time to think about all of this :)
>
> 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.
