On Fri, Jun 19, 2020 at 1:50 PM Bryan C. Mills <bcmi...@google.com> wrote:
>
> On Fri, Jun 19, 2020 at 2:38 PM Ian Lance Taylor <i...@golang.org> wrote:
>>
>> On Fri, Jun 19, 2020 at 9:31 AM Bryan C. Mills <bcmi...@google.com> wrote:
>> >
>> > On Fri, Jun 19, 2020 at 1:30 AM Ian Lance Taylor <i...@golang.org> wrote:
>> >>
>> >> 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.
>> >
>> >
>> > Yes, that is exactly my point: the fact that that program is invalid
>> > implies that type-list interfaces are not consistent with the semantics of
>> > other interface types.
>>
>> I'm sure that I don't really understand what you are saying.
>>
>> But from my perspective using a type list in an interface type used as
>> a type constraint permits certain operations in that generic function.
>> That is a specific feature of generic functions. You seem to be
>> trying to extend that capability to non-generic functions. But that
>> doesn't work.
>
>
> I am not trying to extend that capability to non-generic functions. I am
> pointing out that the fact that generic functions do have that capability
> implies that type-list interfaces — unlike non-type-list interfaces! — would
> have a meaning as type constraints that is incompatible with their meaning as
> non-generic interface types.
>
> (Specifically, they would have the usual interface property that “T
> implements T” except when used as type constraints, and as you note, that
> exception is fundamental to the design of constraints.)
I think that what you are saying is that if I write
type C interface { ... }
func F(type T C) {}
then if C does not have a type list then I can write
F(C)
because C as an interface type has all the methods that are required
by C as a constraint. But if C has a type list then I can't write
that, because C itself is normally not a member of the type list.
If that is what you are saying, then I agree.
I guess the next question is why this matters.
>> > Because the rules for type-list interfaces always have an extra condition
>> > beyond “simply implementing the interface type”, we would be locked into
>> > at least one of the following limitations on the evolution of the language:
>> >
>> > A type-list interface can never be used as a type argument.
>> > Or, a type parameter of an interface type can never be allowed as the
>> > constraint of another type parameter, nor embedded in the constraint of
>> > another type parameter.
>>
>> I don't understand what the second limitation means. The current
>> design draft has no way to require that a type parameter have an
>> interface type. Can you give an example of what you mean?
>
>
> https://go2goplay.golang.org/p/6cu23w3iYHQ
Thanks. Here I think you are suggesting that we should be able to use
a type parameter as a type constraint. I don't agree. It's
fundamental to this design that a generic function provides a contract
for its type arguments. The constraints determine the permitted type
arguments, and they determine the operations permitted in the function
body. If we use a type parameter as a type constraint, that means
that the contract is partially determined by the caller. That serves
no purpose: the caller already controls the type arguments, so there
is no reason for the caller to constrain the type arguments to be
passed. And the generic function body can't determine anything from a
constraint defined by the caller, so it doesn't permit any additional
operations in the function body. So I don't think we should permit
using a type parameter as a type constraint, even if we had some way
to require a type parameter to be an interface type.
>> > Otherwise, we would break the substitution property: the meaning of a
>> > type-list interface would depend upon whether it was written literally in
>> > the source code or passed as a type argument. (That is: the meaning of a
>> > generic declaration instantiated with a given list of argument types would
>> > be different from the meaning of the same declaration with some of its
>> > actual arguments substituted for the corresponding parameters.)
>>
>> Again I'm sure that I don't understand what you are saying. My
>> initial reaction is that of course the meaning of a type-list
>> interface depends on whether it is used as a type constraint or is
>> passed as a type argument. Those are two entirely different
>> operations. You can't use a type parameter as a type constraint. I
>> suppose you could regard that as a limitation of the system, but it's
>> an intentional one.
>
>
> It is already possible to use a type parameter as part of a type constraint,
> as illustrated by the SliceConstraint example.
> That pattern works in a variety of situations, just not as the entire
> constraint or as an interface embedded in the constraint type
> (https://go2goplay.golang.org/p/cYOhEKo-mm0).
>
> The design doc states clearly that “[t]ype constraints are interface types”,
> so it seems oddly inconsistent to allow the parameter to be a component of
> the constraint but not the entire constraint.
Note that when we use a parameter as a component of the constraint we
are requiring type identity. If we were to give a meaning to using a
parameter as a constraint, I think the only possible meaning would be
that the two parameters would be constrained to be identical types. I
don't see a reason to use the value of the type argument.
In general the meaning of constraints is entirely determined by the
function definition, and does not depend in any way on the type
arguments.
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/CAOyqgcV%2B6q6PCWRFeNa2q0OG4q6cr06sYwx_uPqhBmF0ZKQDVQ%40mail.gmail.com.
