> 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 <yiyu...@gmail.com> 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.
