Never mind, I found it. The draft proposal says
To validate the type arguments, each of the contract’s parameter types is
> replaced with the corresponding type argument [...]. The body of the
> contract is then type checked as though it were an ordinary function. If
> the type checking succeeds, the type arguments are valid.
Thanks anyway.
On Friday, September 7, 2018 at 10:17:41 AM UTC-4, Larry Clapp wrote:
>
> contract { var _ map[T]bool }
>
>
> Would this contract allow T to be used in a map to some other type than
> bool? e.g. map[T]int? If so, why? Why is bool a stand-in for "any
> type"? (I apologize if this has been dealt with elsewhere; this is a big
> topic.)
>
> On Thursday, September 6, 2018 at 7:29:55 PM UTC-4, Axel Wagner wrote:
>>
>> On Fri, Sep 7, 2018 at 12:37 AM Ian Lance Taylor <ia...@golang.org>
>> wrote:
>>
>>> On Thu, Sep 6, 2018 at 3:04 PM, Axel Wagner
>>> <axel.wa...@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.
>>
> [snip]
>
--
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.
