To elaborate a bit about the differences between "the type set" and "the set of specific types" and the purpose of the latter - at least as I understand it:
The actual type set is hard to compute, in general <https://github.com/golang/go/issues/45346#issuecomment-813639125>, so using it to define the set of allowed operations on a type is impractical. The easier to calculate set of specific types was introduced, I believe, to fix this problem. It should always be a subset of the actual type set. By being easy to compute, it is useful to determine what operations are allowed on a type parameter in a function body - we can calculate the set of specific types and just verify that an operation is allowed on all of them. As it's a subset of the true type set, this will never allow an operation, which is not allowed by all elements in the type set. But it might disallow operations, which the type set would allow. OTOH, checking if any given type is an element of the type set is easy. So the type set is still useful to determine if a function can be *instantiated* using a given type - as in that case, the type is known and we just need to verify it's in the type set. In short: The type set is used to validate instantiations of a generic function, while the set of specific types is used to validate the body of a generic function. In this case, the set of specific types is smaller, than the actual type set. The type set is `{int}`, but the set of specific types is empty. Therefore, the function should be able to be instantiated with `int`, but the function body should not be allowed to do any operation on the type parameter (which is not allowed by all types). Which is why I'm inclined to believe that the compiler is wrong here - if we think this should work, we probably shouldn't have the set of specific types to begin with. It may seem unfortunate to end with an empty set of specific types (and thus empty set of allowed operations), but it's dictated by the computational difficulty of the problem. And, ultimately, this should only really carry in cases which are pathological. i.e. the way to solve this limitation, is to simply not use `interface{ int; any }`, but instead use `interface { int }`, which has the same type set *and* a non-empty set of specific types (equal to its type set). On Thu, Jan 6, 2022 at 7:23 PM Axel Wagner <axel.wagner...@googlemail.com> wrote: > > > On Thu, Jan 6, 2022 at 7:02 PM Brian Candler <b.cand...@pobox.com> wrote: > >> On Thursday, 6 January 2022 at 17:13:38 UTC axel.wa...@googlemail.com >> wrote: >> >>> On Thu, Jan 6, 2022 at 1:58 PM tapi...@gmail.com <tapi...@gmail.com> >>> wrote: >>> >>>> I don't think your conclusion is right. Otherwise, the following code >>>> doesn't compile, but it does. >>>> >>>> type C interface{ int; any } >>>> >>>> func f[T C](x byte) T { >>>> return T(x) >>>> } >>>> >>> >>> I agree that the compiler and spec seem to disagree here. It seems to me >>> that by the spec, this should not be allowed, as C has no specific types. >>> >> >> But is that true? "Type set" and "specific types" are two different >> concepts, and "specific types" are only required in certain contexts, which >> are called out in the spec. >> > > Correct. One of those is determining if the conversion `T(x)` is legal, if > `T` is a type parameter. Specifically, it only makes it legal if `T` is a > type parameter with specific types. > > It seems that function f[T C] will accept any type which is in the *type >> set* of C - is that not reasonable? >> > > Yes. But the issue isn't the instantiation of `f` (in fact, `f` is not > instantiated in this code), it's the definition. > > >> >> This does of course highlight how complex the language has become with >> the introduction of generics. >> >> -- >> 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/6edaaaf6-87a8-4cb4-9015-8bb007a5d70cn%40googlegroups.com >> <https://groups.google.com/d/msgid/golang-nuts/6edaaaf6-87a8-4cb4-9015-8bb007a5d70cn%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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/CAEkBMfG3ADrXFct0x98BS%3DPyXsp_FxcCLuS-DBKfav_%2B9OHOmg%40mail.gmail.com.
