Because when you define a "type Foo []int" you're definig a new type Foo that is not the same type as []int.
So if the type parameter said "[]E" where E is a comparable then "Foo" wouldn't be allowed because Foo is not the same type as "[]int" (for that you'd need a type alias i.e "type Foo = []int". This is by design since it allows you to define new types you don't want to get accidentally used where you don't want them to.
When defining library functions that are truly generic you may want instead to let them be used on the "underlying type". For example, Sort library authors decided that generally you want it to just work on the underlying type and that's why they added ~ in front of the generic type. Otherwise every invocation of Sort you'd need to convert the type e.g. "slices.Sort([]int(myfoo))".
The other type parameter "E comparable" doesn't need the tilde because "comparable" is not an actual type but a type constraint.
A type constraint is an interface that defines the set of permissible type arguments for the respective type parameter and controls the operations supported by values of that type parameter.
You don't need a tilde because any type that implements that constraint will be accepted. Also any type implementing a constraint that embeds that constraint also works
type Something []string
ensure that the underlying type is a slice
Why do you need a tilda for `S ~[]E`, but not for `E comparable`?
Both are type-constraining annotations, so why two syntaxes?
Because when you define a "type Foo []int" you're definig a new type Foo that is not the same type as []int.
So if the type parameter said "[]E" where E is a comparable then "Foo" wouldn't be allowed because Foo is not the same type as "[]int" (for that you'd need a type alias i.e "type Foo = []int". This is by design since it allows you to define new types you don't want to get accidentally used where you don't want them to.
When defining library functions that are truly generic you may want instead to let them be used on the "underlying type". For example, Sort library authors decided that generally you want it to just work on the underlying type and that's why they added ~ in front of the generic type. Otherwise every invocation of Sort you'd need to convert the type e.g. "slices.Sort([]int(myfoo))".
The other type parameter "E comparable" doesn't need the tilde because "comparable" is not an actual type but a type constraint.
A type constraint is an interface that defines the set of permissible type arguments for the respective type parameter and controls the operations supported by values of that type parameter.
You don't need a tilde because any type that implements that constraint will be accepted. Also any type implementing a constraint that embeds that constraint also works
It is like S: where S = []E where E: comperable.
I like the way Rust has it a lot more but it is still imperfect and feels arbitrary in ways.
I find myself unsure where to put the templatization parameters and it doesn't feel perfectly symmetrical.
Unsure if impl MyType<T> where T: X
is comperable to impl MyType<T: X> Sometimes it needs impl<T> MyType<T> where T: X
1 reply →
Guessing that E is the element, so is not a slice (or more accurately we don’t care if it is a slice or not!)