>
>
> Ok, the alternative of my question is: why []T2 and []T1 have different
> underlying representations when T2 and T1 have the same underlying
> representation?
>
>
There is a difference - the compiler does not split slices and find the
underlying representation of the non-slice part (example
https://play.golang.org/p/hnjNkM77h7)
package main
type T1 string
type T2 T1
type T3 []T1
type T4 T3
type S1 T1
type S2 S1
type S3 []S1
type S4 S3
func main() {
var (
t3 T3
t4 T4
s3 S3
s4 S4
r T1
)
a := T3(t3)
b := T4(t4)
c := T3(t4)
d := T4(t3)
e := T3(s3) //not allowed
f := T3(s4) //not allowed
z := S4(t4) //not allowed
//etc
r2 := S2(r)
v := S3(s3)
w := S4(s4)
x := S3(s4)
y := S4(s3)
The slice is treated as a type unto itself - that is why, in the examples
cross conversion between slice types involving S and T fail.
In the spec ( https://golang.org/ref/spec#TypeName ) types are defined. The
relevant text on underlying types is *"Each type T has an underlying type:
If T is one of the predeclared boolean, numeric, or string types, or a type
literal"*
Type = TypeName | TypeLit | "(" Type ")" .
TypeName = identifier | QualifiedIdent .
TypeLit = ArrayType | StructType | PointerType | FunctionType |
InterfaceType | SliceType | MapType | ChannelType .
In the non slice type (eg String) this corresponds to TypeName, whereas in
the slice (eg []String) example this corresponds to TypeLit (SliceType).
The language specification does not state that type literals are further
analysed for sub-type matches - so it does not happen.
I get that a common expectation is that a full recursive analysis of a
TypeLiteral *might* happen, reducing each sub-element of the TypeLiteral to
its lowest form - but it doesn't happen.
--
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.
For more options, visit https://groups.google.com/d/optout.
