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/CAOyqgcUB0bdsXdKg8_-C%3DG3NzG13GjhiVw0h_xvB1pOrEJRvcw%40mail.gmail.com.
