On Thu, Sep 6, 2018 at 3:04 PM, Axel Wagner
<axel.wagner...@googlemail.com> wrote:
>
> On Thu, Sep 6, 2018 at 9:45 PM Ian Lance Taylor <i...@golang.org> wrote:
>>
>> On Thu, Sep 6, 2018 at 10:29 AM, jimmy frasche <soapboxcic...@gmail.com>
>> wrote:
>>
>> This is clearly a key issue. I happen to think that contracts are
>> fairly clear for the reader: take your type argument and see if the
>> contract body works. I feel that everyone who knows Go will be able
>> to do that. But maybe that's just me.
>
>
> I agree with you on this. But I don't think it's enough. To be type-safe
> (from the author perspective), you also need to do the opposite: Take any
> *other* type and make sure that it *doesn't* pass the contract. Because
> otherwise, you might end up with a program that compiles, but is crashing or
> otherwise invalid. And that's what made me turn against contracts, lately.
>
> I name a couple examples in my blog post (linked upthread), but as it just
> came up during a talk at the Zurich Go Meetup: For example, you might have a
> contract like `t%1`, to ensure you get an integer type (sorry, that is
> ad-hoc the best way I can come up to write that contract). Now, say a
> generic function uses that type-parameter for a loop-counter, counting down:
> `for i := T(N); i >= 0; i-- { … }`. They check that `int` types pass their
> contract and everything goes smoothly. At some point, someone uses the
> function with a `uint` argument and you get an endless loop.
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?
> Now, this example is constructed. It will probably not occur in practice.
> But it illustrates why I believe contracts make it relatively hard to write
> type-safe generic code - because the contract does not only has to allow
> everything you want to do, it also has to disallow anything you don't.
> Expressing that syntactically is much harder.
> This gets exacerbated by implied capabilities (though it's not clear yet if
> and how much they exist): i.e. the compiler could prove that only integer
> types allow `%`, so if you put down that constraint, it also allows `+`,
> `*`, conversions to float…
I think it is clear that we are not going to do that.
> 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.
