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