>
> 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
> <javascript:>> wrote:
>
>> On Thu, Sep 6, 2018 at 3:04 PM, Axel Wagner
>> <axel.wa...@googlemail.com <javascript:>> 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.
