In the following code snippet the last three assignments produce a compilation error:
package main
type (
Foo []float64
Baz [2]float64
Meh map[string]string
Faq chan int
Tet func()
Hue interface{}
Tai bool
Foz string
Bar float64
)
func main() {
var (
foo Foo = []float64{1, 2, 3}
_ []float64 = foo
baz Baz = [...]float64{1, 2}
_ [2]float64 = baz
meh Meh = make(map[string]string)
_ map[string]string = meh
faq Faq = make(chan int)
_ chan int = faq
tet Tet = func() { return }
_ func() = tet
hue Hue = "Hello, World"
_ interface{} = hue
tai Tai = true
_ bool = tai // error
foz Foz = "Hello, World"
_ string = foz // error
bar Bar = 1
_ float64 = bar // error
)
}
This means that, in this example, only bools, strings and floats are not assignable. The reason for this can be found in the specification:
A value x is assignable to a variable of type T ("x is assignable to T") in any of these cases:
- [...]
- x's type V and T have identical underlying types and at least one of V or T is not a named type.
- [...]
(Go Specification: Assignability)
and
[...] Named types are specified by a (possibly qualified) type name; unnamed types are specified using a type literal, which composes a new type from existing types. [...]
Combining this, the reason why the aliased assign does not work is because the types of the last three cases are named. Through this the rule is violated: Two named types are part of the assignment.
Now to my actual question(s):
Why should it not be allowed to assign an aliased string/bool/numeric to an actual string/bool/numeric, as opposed to types like slices and arrays?
What kinds of problems would the lack of this rule cause?
What kinds of problems would the specification of a string as a named type cause?
Thank you in advance.
The assignability rules mean you sometimes have to convert between named types to explicitly say "yes, I mean this string to be used as a Foo," even if they share the same underlying type. This is relevant to things like os.FileMode: it's a number underneath, but type checks will keep you from accidentally passing it to a function that takes an unrelated foo uint32. (Assignability rules affect function calls, too: you can pass an argument of any type that's assignable to the parameter type.)
Generally, this means if you have distinct, potentially confusable uses for an underlying type, you can assign different names to them. Like: the underlying type [][4]float32 could plausibly have RGBASlice, HSVASlice, and XYZWSlice type names assigned. You can't pass a RGBASlice to a function that expects an XYZWSlice. But all can be passed transparently to things that don't care about the meanings of the numbers, like if you have some all-purpose vector-math routines.
So, broadly, by forcing you to convert between named types, Go helps you distinguish between things that might have the same representation in memory even though they have different meanings and are supposed to be used different places.