cc: @ianlancetaylor

Also CC @findleyr.

Thanks for filing this.

As a general rule, I think wherever we can avoid referring to core types the spec gets lighter and the generics implementation gets more useful. However, this benefit is not uniformly distributed. For example, while I think it would be very nice to remove restrictions on struct field access, it is less useful to avoid restrictions on e.g. range statements (do we really need to be able to range over []int|map[string]bool?).

So I think it is a good goal to avoid referencing core types. It would be quite an achievement to avoid all references, but that's probably not strictly necessary. (Also, if we can narrow it down to a just handful of references, perhaps we can phrase restrictions without needing to reference a "core type" abstraction).

@findleyr, I agree that not being able to range over []int|map[string]bool is not a big deal, but I think core types are problematic even for range statements.

For example, I would expect to be able to range over map[string]bool | map[string]struct{}, even though IIUC such a constraint does not have a core type today.

@bcmills I think that's an example of where some restrictions may still be required, but need not be expressed in terms of a "core type" abstraction. For example, we can insist that the key and/or value types be well-defined.

Does the Go team is waiting to release other Generics features or any Core types refactor that should be part of this investigation at some point?
If not, could we add this investigation to a release milestone?

I am trying to understand if there is any current or short-term work that would be preventing this investigation to happen sooner, thanks.

We are all busy and must prioritize among many different issues. Assigning a release milestone won't affect how quickly we focus on this issue. What would matter instead is reasons in favor of, or against, working on this issue. Thanks.