Change https://go.dev/cl/400095 mentions this issue: spec: permit write defined type in type term

CC @griesemer

This seems to me to be potentially confusing. It seems natural to think that ~MyInt only accepts type arguments that are defined as MyInt, but in fact it accepts other types as well.

This change also doesn't seem very necessary. I can write

type MyUnderlyingType = struct { a int }
type MyStruct struct { a int }
type MyOtherStruct struct { a int }
func F[T ~MyUnderlyingType]() {}
var _ = F[MyStruct]
var _ = F[MyOtherStruct]

It seems to me that this gives me the same effect without changing the meaning of ~Type.

This seems to me to be potentially confusing. It seems natural to think that ~MyInt only accepts type arguments that are defined as MyInt, but in fact it accepts other types as well.

I noticed this while prototyping the spec change, and intentionally made the proposal to let this to happen:

<p>
Additionally, two constraints with only embedded type elements (not a method) are the same if their underlying types are the same:
</p>

<pre>
[T ~MyInt]                   // = [T ~int]
[T ~MyStruct]                // = [T ~struct{a int}]
[T ~MyOtherStruct]           // = [T ~struct{b int}]
</pre>

So that we could guarantee the concept of "underlying type" stays with (what I understood) the current meaning in the spec, and also not touch the potentially relevant "core type" concept.

Still, it's quite surprising for me to hear it is "natural to think that ~MyInt only accepts types that are defined as MyInt", because MyInt is used with a tilde, and currently, it refers back to the language predeclared or composite types.

For

func F[T MyInt]()

We might agree on this "natural think", but I can't easily stand for this "natural think".
If we imagine this to happen, it means we will need to permit all defined types to be an "underlying type". That means the "underlying type" concept won't align with the current spec, and it is also not clear what is the core type in this case, also not clear how to differentiate "underlying type" and "core type".

type MyInt int
type MyAnotherInt MyInt
func G[T ~int]().         // 1, underlying type is int
func G[T ~MyInt]()        // 2, underlying type is MyInt
func G[T ~MyAnotherInt]() // 3, underlying type is MyAnotherInt

I also don't know if this "nature think" intended to think that type set defined by 1, 2, and 3 gets smaller and smaller and why this makes sense.

Nevertheless, I have to say I am not a language expert; therefore, can't fully evaluate these two types of thinking and what are the consequences. But I think the main purpose of this proposal is to write code that we can't do today, which adds to your follow up comments:

This change also doesn't seem very necessary. I can write

type MyUnderlyingType = struct { a int }
type MyStruct struct { a int }
type MyOtherStruct struct { a int }
func F[T ~MyUnderlyingType]() {}
var _ = F[MyStruct]
var _ = F[MyOtherStruct]

It seems to me that this gives me the same effect without changing the meaning of ~Type.

This was discussed in #52295.
The trick may be a workaround for simple cases where the underlying type could be written but does not work when it gets complicated:

1. It may not deal with circular struct where the underlying type needs a field to point to itself
2. The underlying type may need to define methods
3. The underlying type may not access or have unexported fields.

Specifically:

package main

import "sync"

type MyComplexStruct struct { // maybe from an external package
	a int
	b *MyComplexStruct
	c sync.Mutex
}

type S = MyComplexStruct

func F[T ~S](t T) {}

func main() {
	F(MyComplexStruct{}) // ERROR
}

A more complicated example could be found in #52295.

Just want add more thoughts regarding the "natural thinking" and how it might gets conflict. The following is how code works today. Hence I think the "underlying type" really means the language predeclared or composite types:

package main

type Type struct{}      // the underlying type of Type is struct{}
type MyType Type        // the underlying type of MyType is struct{}
type MyAnotherType Type // the underlying type of MyAnotherType is struct{}

func F[T ~struct{}](t T) {} // Today

func main() {
	x := Type{}
	y := MyType{}
	z := MyAnotherType{}

	F(x) // OK
	F(y) // OK
	F(z) // OK
}

Say if we can write this:

func F[T ~MyType](t T) {} 

and disallowing

F(Type{})

Then I guess we also can't write:

F(MyAnotherType{})

Because MyAnotherType is not defined by MyType.
Now, let's have

type MyThirdType MyType
type MyFouthType MyThirdType

Can we do the following? and why? Align with Ian's comments in #52318 (comment), this is possible:

F(MyFouthType{})

Should we say "the underlying type of MyFouthType is MyType"?
or, should we say "the core type of MyFouthType is MyType"?
or, should we say "MyFouthType is 'derived' type from MyType"?

Either way, the "natural thinking" seems to introduce an inconsistent behavior comparing to how the code works today.

This seems to me to be potentially confusing. It seems natural to think that ~MyInt only accepts type arguments that are defined as MyInt, but in fact, it accepts other types as well.

After rethinking this argument with a fresh mind, I see the root issue is that ~ cannot state the "direction" of type approximation, and the key ambiguity at the moment is how to compare the "size" of the type set ~MyInt and ~int when:

type (
    A  int
    B A
    C A
    D B
    E B
    F C
)

int -> A -> B -> D
       |    |
       |    + -> E
       |
       + -> C -> F

There are three cases of understanding:

1. This proposal (similar to == B): ~B includes int, and any successor types derived from int, such as A, B, ..., E, and F.
2. Ian's intuition (similar to >= B): ~B includes its successor types derived from B, e.g., B, D, E, and any subsequent types from B but not include its ancestor A or int, or sibling C's successors F.
3. One more possibility (similar to <= B): ~B includes all of its ancestors A and int, and its direct successor types D, E, but not C, F.

This sense comes from the type declaration type MyInt int can be considered as an ancestor of int or can be considered as something approximately equivalent to int. Should we consider ~MyInt as something approximately equivalent to int?

For simplicity, I think the 1st option could fit because it considers types that are underlying the same. The 2nd option conveys a bit more cognitive load, where a person needs to understand the "order" of defined types. This could be very complicated when types are redefined very differently at scale.

One additional downside for the 2nd is about the ~ operator itself: it is not an asymmetric operator similar to < or >. Maybe one could think of a difference between ~T and T~,
but I would imagine this further complicates the language, which seems to deviate from the initial goal of the proposal.

We're not going to make any generics changes any time soon, so putting this on hold.

If the purpose of the tilde is tied to the normal form of a type, then the current behavior is appropriate. Considering that a named type may have associated methods, and that aliasing that type, a different (e.g. empty) set of methods is associated, such an assertion of structural compatibility does not guarantee compatibility of meaning.

Example 1, supposing the following:

type A struct{X int; Y float;}
type B struct{X int; Y float;}
type C A

What should "~A" mean? Would it mean "Assignable to struct{X int; Y float;} " or "Derived at some point from A".

If the former, then it's misleading. If the former, the exclusion of B is suggested, but B is apparently valid. If the former, you assert that any type, having any particular meaning, which is coercible to A, can be re-expressed in terms of A, with meaning as if it were A.

If the latter, you're proposing a new facility which is potentially problematic. If the latter, you propose another overhaul of the type system.

Example 2, suppose the following:

package alpha
type A struct{X int; Y float;}
type b A
type C b

package beta
import "alpha"
func f[T ~alpha.A](x T) T { return x; }
func main() {
    c := f(alpha.C{1,1.0})
}

The type resolution must resolve a lineage which includes an unexported type. How can that be resolved?

The contrary case, where ~A means "Assignable to A, as shorthand for ~struct{X int; Y float} is admittedly shorter, but it also requires special knowledge to understand.

For what it's worth, the supportable proposal would be to suggest some kind of "type as value" scheme, such that one could reason about the types of X, versus Y and Z, such as if type of X equals type of Y else if type of X equals type of Y. However, if you wanted this, you can accomplish it by trying bad assignments and recovering. If this is a feature that then meaningfully moves the boundaries of what can be expressed, at least then it can be proven that the mechanism is possible and the facility has value, and a proposal could address the performance implications of intending a panic/recover cycle. Further, such improvements would benefit the rest of the language, as well.

Sorry, I don't understand where your "Assignable to ..." came from. The whole conversation context is about type constraints. Your example

f(alpha.C{1,1.0})

instantiates f to:

func f(x alpha.C) alpha.C { return x; }

There is nothing in relation to assignability to alpha.A whatsoever.