Re: [go-nuts] Re: Update to generics proposal
I was specifically talking about Ian's example, where no methods are
defined.
On Tuesday, 6 April 2021 at 15:57:18 UTC+2 Thomas Bushnell, BSG wrote:
> On Mon, Apr 5, 2021 at 9:04 PM yiyus wrote:
>
>> > then I guess you mean that interface { MyInt } will accept any type
>> > argument whose underlying type is the same as the underlying type of
>> > MyInt. But that seems strange. There is no connection between MyInt
>> > and MyInt2, except that they happen to be defined in terms of the same
>> > underlying type.
>>
>> This is an excellent example. Indeed, I think that MyInt and MyInt2
>> should satisfy the same constraints (because they support exactly the same
>> operations). Just like MyString and MyString2 will implement the Stringer
>> interface if they happen to have a String method, and there is no way to
>> constrain the types which can implement Stringer, I think that any type
>> that can be used in a generic function like an int should satisfy
>> interface{int} (and therefore also interface{MyInt} and interface{MyInt2}).
>>
>
> But they don't necessarily support exactly the same operations if they
> have different methods. So maybe you mean that MyInt and MyInt2 should
> satisfy the same constraints if they have the same underlying type and
> happen to support the same method sets.
>
--
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/520da01c-b19f-443d-ae88-98221ceb2dccn%40googlegroups.com.
Re: [go-nuts] Re: Update to generics proposal
On Mon, Apr 5, 2021 at 9:04 PM yiyus wrote:
> > then I guess you mean that interface { MyInt } will accept any type
> > argument whose underlying type is the same as the underlying type of
> > MyInt. But that seems strange. There is no connection between MyInt
> > and MyInt2, except that they happen to be defined in terms of the same
> > underlying type.
>
> This is an excellent example. Indeed, I think that MyInt and MyInt2 should
> satisfy the same constraints (because they support exactly the same
> operations). Just like MyString and MyString2 will implement the Stringer
> interface if they happen to have a String method, and there is no way to
> constrain the types which can implement Stringer, I think that any type
> that can be used in a generic function like an int should satisfy
> interface{int} (and therefore also interface{MyInt} and interface{MyInt2}).
>
But they don't necessarily support exactly the same operations if they have
different methods. So maybe you mean that MyInt and MyInt2 should satisfy
the same constraints if they have the same underlying type and happen to
support the same method sets.
--
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/CA%2BYjuxsXpMcQTGVbSFvmS%2BhSsot8BT7_RVx1Pf_euhtdRuZSbw%40mail.gmail.com.
Re: [go-nuts] Re: Update to generics proposal
> then I guess you mean that interface { MyInt } will accept any type
> argument whose underlying type is the same as the underlying type of
> MyInt. But that seems strange. There is no connection between MyInt
> and MyInt2, except that they happen to be defined in terms of the same
> underlying type.
This is an excellent example. Indeed, I think that MyInt and MyInt2 should
satisfy the same constraints (because they support exactly the same
operations). Just like MyString and MyString2 will implement the Stringer
interface if they happen to have a String method, and there is no way to
constrain the types which can implement Stringer, I think that any type
that can be used in a generic function like an int should satisfy
interface{int} (and therefore also interface{MyInt} and interface{MyInt2}).
@rog: yes, you are right. For example, interface{MyInt} would be different
from interface{int} if MyInt had any method. Then, under my proposal, in
order to fulfill the interface{MyInt} constraint, it would be enough to
have the same methods and support the same operations.
On Tuesday, 6 April 2021 at 00:35:26 UTC+2 Ian Lance Taylor wrote:
> On Mon, Apr 5, 2021 at 3:02 PM yiyus wrote:
> >
> > > More generally, if we omit approximation elements, it's a bit odd that
> > > if I write "int" I mean "an infinite set of types including int". It
> > > seems clearer to require people to explicitly indicate that they want
> > > to match the infinite set of types.
> >
> > What I propose is not that "int means an infinite set of types including
> int", what I propose is that interface{int} means the types that support
> the operations of the int type. The fact that this "int" is inside an
> interface definition is important. From my point of view, defining an
> interface already is an explicit way to indicate that you want to match an
> infinite set of types.
> >
> > This would solve, in my opinion, the problem of interface{int} and
> interface{MyInt} looking similar but with different meanings. They would
> mean the same, and I think that is fine. Could you (or someone else) give
> an example of when would it be useful that they mean different things in
> the context of generic constraints?
>
> Given
>
> type MyInt int
> type MyInt2 int
>
> then interface{ int } as a constraint will accept either MyInt or
> MyInt2 as a type argument, but interface { MyInt } will only accept
> MyInt as a type argument.
>
> Or if that is not the case, if interface { MyInt } does accept MyInt2,
> then I guess you mean that interface { MyInt } will accept any type
> argument whose underlying type is the same as the underlying type of
> MyInt. But that seems strange. There is no connection between MyInt
> and MyInt2, except that they happen to be defined in terms of the same
> underlying type.
>
> 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/ddb726e3-5e65-4e3d-b331-8a493a70455dn%40googlegroups.com.
Re: [go-nuts] Re: Update to generics proposal
On Mon, Apr 5, 2021 at 3:02 PM yiyus wrote:
>
> > More generally, if we omit approximation elements, it's a bit odd that
> > if I write "int" I mean "an infinite set of types including int". It
> > seems clearer to require people to explicitly indicate that they want
> > to match the infinite set of types.
>
> What I propose is not that "int means an infinite set of types including
> int", what I propose is that interface{int} means the types that support the
> operations of the int type. The fact that this "int" is inside an interface
> definition is important. From my point of view, defining an interface already
> is an explicit way to indicate that you want to match an infinite set of
> types.
>
> This would solve, in my opinion, the problem of interface{int} and
> interface{MyInt} looking similar but with different meanings. They would mean
> the same, and I think that is fine. Could you (or someone else) give an
> example of when would it be useful that they mean different things in the
> context of generic constraints?
Given
type MyInt int
type MyInt2 int
then interface{ int } as a constraint will accept either MyInt or
MyInt2 as a type argument, but interface { MyInt } will only accept
MyInt as a type argument.
Or if that is not the case, if interface { MyInt } does accept MyInt2,
then I guess you mean that interface { MyInt } will accept any type
argument whose underlying type is the same as the underlying type of
MyInt. But that seems strange. There is no connection between MyInt
and MyInt2, except that they happen to be defined in terms of the same
underlying type.
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/CAOyqgcUB0bdsXdKg8_-C%3DG3NzG13GjhiVw0h_xvB1pOrEJRvcw%40mail.gmail.com.
Re: [go-nuts] Re: Update to generics proposal
On Mon, 5 Apr 2021, 21:58 yiyus, wrote: > A type and its underlying type support exactly the same operations > FWIW I don't believe that's the case. A type may have methods (each with at least one corresponding operation) that its underlying type does not. -- 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/CAJhgacgaJgVBYnfmK1zXyRTuAeA%3D4ga4Je0-V_Ur5Kh5G4uy4w%40mail.gmail.com.
Re: [go-nuts] Re: Update to generics proposal
> More generally, if we omit approximation elements, it's a bit odd that
> if I write "int" I mean "an infinite set of types including int". It
> seems clearer to require people to explicitly indicate that they want
> to match the infinite set of types.
What I propose is not that "int means an infinite set of types including
int", what I propose is that interface{int} means the types that support
the operations of the int type. The fact that this "int" is inside an
interface definition is important. From my point of view, defining an
interface already is an explicit way to indicate that you want to match an
infinite set of types.
This would solve, in my opinion, the problem of interface{int} and
interface{MyInt} looking similar but with different meanings. They would
mean the same, and I think that is fine. Could you (or someone else) give
an example of when would it be useful that they mean different things in
the context of generic constraints?
Thank you for answering (and your work in the proposal, it keeps getting
better!).
On Monday, 5 April 2021 at 23:08:00 UTC+2 Ian Lance Taylor wrote:
> On Mon, Apr 5, 2021 at 1:58 PM yiyus wrote:
> >
> > I may have missed something, but I have problems to understand what is
> the goal of the proposal. It says:
> >
> > > The purpose of introducing type lists in the generics proposal was to
> specify the operations available to type parameters in parameterized
> functions.
> >
> > I do not see how approximation elements help to solve this problem. A
> type and its underlying type support exactly the same operations, so it
> should not be necessary to make the distinction. If union elements
> represented the set of types which allow all the operations common to all
> types in the union, the above goal would be fulfilled.
> >
> > A few times in this thread, it has been said that it can be useful to
> explicitly specify the allowed types. But I think that if this is indeed a
> goal, it needs to be better justified than referring to previous
> discussions. In particular, I did not find anything in #41716 that
> convinces me that explicit types are useful to define type constraints.
> >
> > I think we will agree interfaces in go are very useful because they
> define behavior instead of a fixed set of types, I would like to know what
> makes the case for constraints different.
>
> Thanks for the comment.
>
> I agree that approximation elements do not solve the problem of
> specifying which operations are available to type parameters.
>
> In the currently published generics proposal, not including the newly
> proposed issue #45346, we permit both `type int" and "type MyInt".
> But although they look quite similar they mean different things.
> Writing "type int" matches all types whose underlying type is "int".
> Writing "type MyInt" matches only "MyInt". Both are meaningful, but
> it's odd that two constructs that look so similar mean different
> things. Adding approximation elements fixes that problem.
>
> More generally, if we omit approximation elements, it's a bit odd that
> if I write "int" I mean "an infinite set of types including int". It
> seems clearer to require people to explicitly indicate that they want
> to match the infinite set of types.
>
> 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/9ade8de8-c982-4ffa-8e17-2561b7a8e35bn%40googlegroups.com.
Re: [go-nuts] Re: Update to generics proposal
On Mon, Apr 5, 2021 at 1:58 PM yiyus wrote: > > I may have missed something, but I have problems to understand what is the > goal of the proposal. It says: > > > The purpose of introducing type lists in the generics proposal was to > > specify the operations available to type parameters in parameterized > > functions. > > I do not see how approximation elements help to solve this problem. A type > and its underlying type support exactly the same operations, so it should not > be necessary to make the distinction. If union elements represented the set > of types which allow all the operations common to all types in the union, the > above goal would be fulfilled. > > A few times in this thread, it has been said that it can be useful to > explicitly specify the allowed types. But I think that if this is indeed a > goal, it needs to be better justified than referring to previous discussions. > In particular, I did not find anything in #41716 that convinces me that > explicit types are useful to define type constraints. > > I think we will agree interfaces in go are very useful because they define > behavior instead of a fixed set of types, I would like to know what makes the > case for constraints different. Thanks for the comment. I agree that approximation elements do not solve the problem of specifying which operations are available to type parameters. In the currently published generics proposal, not including the newly proposed issue #45346, we permit both `type int" and "type MyInt". But although they look quite similar they mean different things. Writing "type int" matches all types whose underlying type is "int". Writing "type MyInt" matches only "MyInt". Both are meaningful, but it's odd that two constructs that look so similar mean different things. Adding approximation elements fixes that problem. More generally, if we omit approximation elements, it's a bit odd that if I write "int" I mean "an infinite set of types including int". It seems clearer to require people to explicitly indicate that they want to match the infinite set of types. 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/CAOyqgcX-oBP4r9me_9fwmU6adXhxSbyjG8AH2vEBUNdv0n3%2Bjw%40mail.gmail.com.
Re: [go-nuts] Re: Update to generics proposal
I may have missed something, but I have problems to understand what is the goal of the proposal. It says: > The purpose of introducing type lists in the generics proposal was to specify the operations available to type parameters in parameterized functions. I do not see how approximation elements help to solve this problem. A type and its underlying type support exactly the same operations, so it should not be necessary to make the distinction. If union elements represented the set of types which allow all the operations common to all types in the union, the above goal would be fulfilled. A few times in this thread, it has been said that it can be useful to explicitly specify the allowed types. But I think that if this is indeed a goal, it needs to be better justified than referring to previous discussions. In particular, I did not find anything in #41716 that convinces me that explicit types are useful to define type constraints. I think we will agree interfaces in go are very useful because they define behavior instead of a fixed set of types, I would like to know what makes the case for constraints different. On Sunday, 4 April 2021 at 22:39:46 UTC+2 rog wrote: > On Sun, 4 Apr 2021 at 00:48, Eltjon Metko wrote: > >> I was fully expecting for floodgates of comments to open again but it >> seems we have reached a point of maturity in the generics proposal. >> The new proposal really makes the intent much clearer both on the exact >> vs underlying type match front and the syntax gives us a more familiar >> union intent. >> So in that light this proposal is a welcome change by itself. >> >> If this would allow us then later to switch on the matched type >> (preferably without type assertion, along the lines of the comment in >> https://github.com/golang/go/issues/45346#issuecomment-812557199 ) >> than it would make this implementation of generics much more useful. >> > > FYI because discussion on that was starting to disrupt the original > proposal, I created > a specific issue for the type switch construct suggested in that comment: > > https://golang.org/issue/45380 > > -- 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/4c88298e-9fce-462c-bbdf-8649f714a5dcn%40googlegroups.com.
Re: [go-nuts] Re: Update to generics proposal
On Sun, 4 Apr 2021 at 00:48, Eltjon Metko wrote: > I was fully expecting for floodgates of comments to open again but it > seems we have reached a point of maturity in the generics proposal. > The new proposal really makes the intent much clearer both on the exact vs > underlying type match front and the syntax gives us a more familiar union > intent. > So in that light this proposal is a welcome change by itself. > > If this would allow us then later to switch on the matched type > (preferably without type assertion, along the lines of the comment in > https://github.com/golang/go/issues/45346#issuecomment-812557199 ) > than it would make this implementation of generics much more useful. > FYI because discussion on that was starting to disrupt the original proposal, I created a specific issue for the type switch construct suggested in that comment: https://golang.org/issue/45380 -- 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/CAJhgacgLVcYTdYWQpyhiU5tDzZ6uEdnZYr-gO2xgY-U90OxzDQ%40mail.gmail.com.
[go-nuts] Re: Update to generics proposal
I was fully expecting for floodgates of comments to open again but it seems we have reached a point of maturity in the generics proposal. The new proposal really makes the intent much clearer both on the exact vs underlying type match front and the syntax gives us a more familiar union intent. So in that light this proposal is a welcome change by itself. If this would allow us then later to switch on the matched type (preferably without type assertion, along the lines of the comment in https://github.com/golang/go/issues/45346#issuecomment-812557199 ) than it would make this implementation of generics much more useful. On Friday, April 2, 2021 at 1:00:06 AM UTC+2 Ian Lance Taylor wrote: > We've just posted a potential update to the generics proposal at > https://golang.org/issue/45346. This clarifies and simplifies the > type lists that appear in interfaces, and let's us drop the "type" > keyword used to mark such lists. > > 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/f6cf4e9f-5d8c-44cc-92de-aaa3915f155fn%40googlegroups.com.
