On Fri, Sep 7, 2018 at 12:37 AM Ian Lance Taylor <i...@golang.org> wrote:
> On Thu, Sep 6, 2018 at 3:04 PM, Axel Wagner
> <axel.wagner...@googlemail.com> wrote:
> Interesting point. But is there any way to solve it short of
> explicitly listing types? Is there any generics system in any
> language that avoids this problem?
>
I'm not saying this would be the solution, but since you asked: Refinement
types (implemented e.g. in Liquid Haskell).
But FWIW, I was using that as an example. There are others, where e.g.
range allows ranging, but has vastly different semantics for string, map,
channel and slice. Or the string(v) example I mentioned, where []rune
passes the contract
contract foo(v T) {
for i, b := range string(v) {
}
}
But if the author was not considering that, might end up with unexpected
results when indexing. Or make(T, N), which is semantically very different
for maps, channels and slices (among other things, for slices,
len(make(T,N)) == N, for the others len(make(T,N)) == 0).
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.
I believe that these cases will become more and more clear, when it comes
to actually write a type-checker, so I don't even really think we have to
talk about all of them or compile a list. I just went away from having
these conversations with the clear impression that contracts are a
non-obvious way to express constraints.
I think it is clear that we are not going to do that.
>
But there will be *some* implied capabilities, I assume (and FWIW, the
example I mentioned is IMO pretty similar to ==/!= and </<=/>/>=). For
example, the design explicitly calls out that == will allow using something
as a map-key:
https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md#map-keys
Note, that contract { var _ map[T]bool } would also work and be explicit.
But it already shows that at least *some* implicit constraints will
probably be desirable.
I understand the arguments in favor of contracts. Personally, I just tend
to think that the disadvantages outweigh them. But that's just, like, my
opinion :) There's still lots of time to see.
> Of course that doesn't *have* to happen - you could just literally only
> > allow the expressions given in the contract, but then the contract
> > potentially becomes very verbose, as it has to cover lots of ground. For
> > example, `a[0]` allows integer-indexing, but it technically only allows
> to
> > pass 0. Extending that to arbitrary integers is what's probably going to
> > happen (and an example of an implicit capability) - but then that code is
> > less type-safe then it needs to be, as Arrays already provide tight
> bounds
> > for constant-indices. You can say that `a[N]` then allows indexing with
> any
> > constant <= N (to make those bounds explicit), but at that point I would
> > criticize that the argument "contracts are just familiar Go syntax"
> becomes
> > less and less convincing, because you are introducing all these special
> > semantical meanings to expressions.
>
> Sure, but I didn't introduce them. Go already permits indexing [N]int
> with variables with values larger than N. Go has no way of expressing
> that kind of type constraints. I don't see any reason why we should
> try to express it in a generics implementation.
>
> 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.
