On Sat, Aug 3, 2019 at 2:11 AM, Ian Lance Taylor <i...@golang.org> wrote:
> You're right, I wrote it wrong. Actually I'm not sure how to write that
> contract. Ideally we want to say that T is either comparable or has the
> Equal(T) bool method, but there is no way to write that. We can embed
> comparable(T), but we can't do that in a disjunction with Equal(T) bool.
So I guess I was building castles in the sky, then. Though, just allowing
this does seem like a viable option. I would guess that the reason not to
allow disjunction between contracts or between constraints on different
types is so that whether each type satisfies a contract can be decided
without reference to the constraints on any other type. Allowing
disjunction between single-parameter contracts applied to the same type
would preserve this property, and the syntax of using these contracts as
constraints would make the restriction that they have to be applied to the
same type fall naturally out of the syntax. You lose the property that the
constraints for any particular type parameter are already in conjunctive
normal form, but you already need to do normalization to check the
conjunctive normal form against the disjunctive normal form in order to
determine whether one contract allows its parameter to satisfy another
contract (when calling generic code from generic code).
As for the generic contracts I was showing, they would be very useful if
this were allowed, but I can understand the teachability hazard of having
two kinds of type parameters on a single declaration. The draft already has
two kinds of type parameters, since contract parameters are different from
regular type parameters, but as long as you never have both kinds of
parameters in play, people don't necessarily need to understand the
distinction between them.
On Sat, Aug 3, 2019 at 2:11 AM, Ian Lance Taylor <i...@golang.org> wrote:
> On Fri, Aug 2, 2019 at 9:25 PM Steven Blenkinsop <steven...@gmail.com>
> wrote:
> >
> > On Fri, Aug 2, 2019 at 6:55 PM 'Axel Wagner' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
> >>
> >>
> >> contract Comparable(T) {
> >> T comparable, Equal(T) bool
> >> }
> >
> >
> > Wait, does this work? I mean, `comparable` is a contract, but it's being
> used as a constraint.
>
> You're right, I wrote it wrong. Actually I'm not sure how to write
> that contract. Ideally we want to say that T is either comparable or
> has the Equal(T) bool method, but there is no way to write that. We
> can embed comparable(T), but we can't do that in a disjunction with
> Equal(T) bool.
>
>
> > The same issue comes up with the
> >
> > switch T.(type) { ... }
> >
> > idea. Even if you're only constraining one type at a time like this, you
> might still need to express a relationship to another type parameter.
> Unless this is allowed:
> >
> > switch (type) {
> > case comparable(T): ...
> > case Equaler(T): ...
> > }
>
> I suspect that switch T.(type) would have to only permit disjunctions
> listed in the contract for T.
>
> 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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CANjmGJsTFyOMFC5i_5UM5Vpb%2Bpfu-YLkAAmNnMRTkhp_jyKMAg%40mail.gmail.com.
