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