> > I get that it avoids introducing those properties directly into the > > language but it also locks the language into those properties. You can > > never change https://github.com/golang/go/issues/19113 after > > introducing contracts because there could be a contract somewhere that > > uses 1 << u instead of contracts.Unsigned. > > This is an interesting point but I'm not yet convinced. The effect of > adopting issue 19113 would be that the contract would accept types > that it previously did not accept. But any polymorphic function using > that contract would still compile. And any call to that polymorphic > function would still compile and work correctly. So what you are > arguing is that we could not make a change that would cause a contract > to accept additional types. I've been questioning why it is important > for a contract to reject types, and I'm still questioning that.
That's true, it would be somewhat analogous to removing a method from an interface. It still accepts all the types it previously accepted and accepts more. The analogy breaks down because code calling the removed method would break if it attempted to call the now missing method. Generic code satisfying the contract that relied on the property that m - n > 0 for all m, n would continue to run in the absence of this now missing property when instantiated with a signed number. Though it may not do so correctly. Unlike the missing method, the missing property is harder to detect. It's easy to detect 1 << u in contracts but unless you know that it was written previous to the version of Go that allowed signed shifts you can't update it to contracts.Unsigned(u). If it was written later it could just mean "any integral number and I'm using it as the amount to shift by". To avoid the polysemy, you have to use the contracts package from the start. You avoid adding the notion of unsigned-ness into the language directly but by creating a mechanism that, for the built in types, can effectively only be used by the standard library. Contracts would definitely disallow a change like https://github.com/golang/go/issues/24529 That's a backwards-incompatible change now but it's rarely used and easy to detect and to automatically fix. After contracts it would likely be as rarely used but much harder to detect and automatically fix. > I guess that by special rules you mean the fact that == permits !=, > and that < permits other comparison operators. Are there other > special rules you mean? These rules seem to confuse people and I'm > increasingly inclined to think that we should just drop them. If you drop them that simplifies things but also creates further reliance on the contracts package since no one is going to want to enumerate all comparisons used when they can just say contracts.Ordered(T). It also means that you can have contracts like contract Less(t T) { t < t } contract Greater(t T) { t > t } While these accept exactly the same types, they accept completely different code in the implementation. > It is like solving a puzzle because you are trying to figure out how > to exclude some types. Why are you doing that? Why not just describe > the types you accept, and not worry about other types? Just as we do > for interface types? > 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. This is an artificial example that I would hope never comes up in practice, but if you bear with me on it I think it illustrates several points: contract complex(s S, t T) { s.F[t] > <-t.G(s) } This is clearly written in code golf style. It can be written more explicitly as: contract complex(s S, t T) { var fieldF = s.F var indexResult = fieldF[t] var selG = t.G var invocationResult = selG(s) var channelResult = <-invocationResult indexResult > channelResult } To be fair, I said more explicitly—not more clearly! You can't use the contracts package to simplify this because indexResult and channelResult aren't types, they're values of an unspecified type that is entirely implicit in the contract definition. So if < doesn't imply the other operators on ordered types you have to do contract complex(s S, t T) { var a = s.F[t] var b = <-t.G(s) a == b a != b a < b // etc. } You could introduce a third type parameter like contract complex(s S, t T, _ U) { var a U = s.F[t] var b U = <-t.G(s) contracts.Comparable(U) } But in addition to having an extra, arguably useless type parameter to carry around, this is a different contract. It only asserts that s.F[t] and <-t.G(s) are assignable to U whereas the original asserted they were identical types (arguably fine). You could special case contracts-in-contracts to allow expressions of a type to be used as that type when composing contracts. Then you could write something like contract complex(s S, t T) { var a = s.F[t] contracts.Comparable(a) contracts.IdenticalType(a, <-t.G(s)) } That does give rise to meta-contracts like IdenticalType that exist only to be used with this special case, though. (Just so no one thinks I've cheated and made up an impossible contract, here are some examples that satisfy it: type S1 struct { F []T } type T1 int func (T1) G(s S1) chan T1 type S2 struct { F map[*T2]float64 } type T2 struct { G func(S2) chan float64 } The contract is satisfied by the pairs (S1, T1), (*S1, T1), (S1, *T1), (*S1, *T1), (S2, *T2), and (*S2, *T2).) All of that said I do think contracts would work and I agree that they are simple. They're simple to implement (assuming a sub-exponential type inference algorithm exists). They keep the language simple in that it adds few things to the spec. It's relatively mechanical to extract a contract from an existing non-generic implementation. My problem with them is that they are the wrong kind of simple. They are not simple in the sense of being simple to reason about in general. They are not simple in the sense that they are not orthogonal to interfaces. They are not simple in that let you get overly specific about some things that no one should care about but give no means whatsoever to express other things that one would care about. I mean you could say that about all code but this is a metatype system not regular code, despite appearances. Maybe these are curmudgeonly concerns. It's not a technical argument, but it still just doesn't sit right with me. -- 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.
