The key sentence from the draft is this:
"If the contract body uses a type in a certain way, the actual
function is permitted to use the type in the same way."
I like the idea of this, and it feels like it *should* be intuitive,
but the problem is that "in a certain way" needs to be very well
defined.
For example, if I've used a type argument parameter as a key in a map,
can we assume that the "way" is "using as key in a map" or "using as
comparable value"?
If I'm passing an argument to a function F, is the implied contract
that "you can call F with that argument" or "you can call any function
with the same argument type as F with that argument" ?
On 7 September 2018 at 15:33, Larry Clapp <la...@theclapp.org> wrote:
> 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.
--
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.
