On Wed, Jun 17, 2020 at 7:58 PM 'Bryan C. Mills' via golang-nuts
<golang-nuts@googlegroups.com> wrote:
>
> On Wednesday, June 17, 2020 at 12:08:59 AM UTC-4 Ian Lance Taylor wrote:
>>
>> On Tue, Jun 16, 2020 at 9:04 PM Xie Zhenye <xiez...@gmail.com> wrote:
>> >
>> > I agree. constraint is different from normal interface. It's better to use
>> > type SomeConstraint constraint {} than type SomeConstraint interface {}
>>
>> That is an option, but then we would have two different concepts,
>> constraints and interfaces, that are very very similar. It's not
>> clear that that is better.
>
>
> I think we already have two very different concepts — we're just conflating
> them together by giving them the same name.
> As far as I can tell, the semantics of non-type-list interface types and the
> semantics of type-list interface types are not compatible.
>
> Today, if we have two interface types T1 and T2, with T1's method set is a
> superset of T2's, then any value assignable to T1 is also assignable to T2:
> that is, T1 is a subtype of (not just assignable to!) T2. That observation is
> also reflected in the Featherweight Go paper, in which a type argument
> satisfies a type constraint if (and only if) the argument is a subtype of the
> constraint.
>
> Based on the semantics of type-lists in type constraints, I would expect that
> a run-time interface type containing a type list would mean “an interface
> value whose dynamic type is one of the listed types”, or perhaps “an
> interface value whose dynamic type has one of the listed types as its
> underlying type”. For consistency, such interfaces should also have the same
> sort of subtyping relationship: if type T1's type-list is a strict subset of
> T2's type-list, then any value assignable to T1 (including a variable of type
> T1 itself!) should be assignable to T2.
>
> So, for example:
> type SmallInt interface { type int8, int16 }
> should be a subtype of
> type MediumInt interface { type int8, int16, int32 }
>
> However, in the current design draft, a constraint that is a type-list
> interface allows use of the operators common to the types in the list.
> In the presence of type-list subtypes of interface types, the semantics for
> those operators would be confusing at best. Consider the program:
>
> func Add(type T MediumInt)(x, y T) T {
> return x + y
> }
>
> func main() {
> var a int8 = 127
> var b int16 = 1
> fmt.Println(Add(SmallInt)(a, b)) // Should this print 128, or -128?
> }
I'm not sure whether it affects your point, but I want to point out
that this program is invalid. The MediumInt type constraint accepts
any type whose underlying type is int8, int16, or int32. The type
SmallInt, an interface type, is not one of those types. So you are
not only extending the design draft to permit SmallInt to be an
ordinary interface type, you are extending the meaning of a type list
in a constraint to accept an interface type that implements the type
constraint. That can't work, and this example shows why it can't
work: you can't add an int8 value and an int16 value.
This code is acting as though, if ordinary interface types could have
type lists, it would be OK to write
func Add2(x, y SmallInt) SmallInt { return x + y }
That is not OK, even though SmallInt has a type list. Even though
every type in theSmallInt type list supports +, they don't support +
with every other type in the type list.
> So type-lists as they are defined in the current draft either cannot have the
> subtyping properties of ordinary interfaces, or must have a meaning as type
> constraints that is fundamentally different from their meaning as interfaces.
> Either way, they don't seem at all consistent with ordinary interfaces to me,
> so I would prefer that we not call them interfaces.
Maybe this is still true. I'm not sure. But I don't yet see a reason
to think that this is true.
Thanks.
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/CAOyqgcW%2BM1nJyS8cLz1JFHCW17mjM09RCH6%2BDnWPO4A8TRGpTw%40mail.gmail.com.
