>
> "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.
"This is described in more detail later." :)
I think I quoted the relevant bit already, but perhaps I'm mistaken.
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"?
I haven't finished reading the actual draft yet, just the overview, but I
have read some of it. On the assumption that you were not asking
rhetorically, I think I'd record these to contract like so:
contract foo(x T) {
var _ = map[T]bool{}
}
contract bar(x T) {
var _ bool = x == x
}
and I think that they are equivalent: any T that satisfies foo will satisfy
bar, and vice-versa.
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" ?
contract baz(x T) {
F(x)
}
func F(x K) {...}
>From the spec on function calls, "arguments must be single-valued
expressions assignable to the parameter types of F".
So for this to type-check, values of type T would have to be assignable to
values of type K, and that's it.
Again, I think the bit I quoted is the relevant part:
>> 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.
So ... is there something I'm missing? I'm not caught up on the whole
draft, never mind all the discussion around it, so that's entirely possible.
— L
On Friday, September 7, 2018 at 12:26:16 PM UTC-4, rog wrote:
>
> 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
> <javascript:>> 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...@googlegroups.com <javascript:>.
> > 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.
