On Fri, Aug 26, 2016 at 9:46 PM, T L <tapir....@gmail.com> wrote: > >> "You are suggesting that there is an extra rule to forbids converting []T1 >> to > []T2 when T1 and T2 have the same underlying representation." > > No. I understand []T1 can't be converted to []T2 when T1 and T2 have > different underlying representation. > > Ok, the alternative of my question is: why []T2 and []T1 have different > underlying representations when T2 and T1 have the same underlying > representation?
They don't. If T2 and T1 have the same underlying representation, then []T2 and []T1 have the same underlying representation. >> "despite the overall prohibition on converting []T1 to > []T2, you are permitted to convert them exactly when T1 and T2 have > the same underlying representation. That rule is much more complex > than the current rule. It means that people reading Go code have to > understand when T1 and T2 have the same representation." > > So you mean there is no implementation obstacles to allow converting []Age > to []int? That is correct. > The prohibition is just to make people less confused. I would say that it is to make the language simpler. There are fewer things that people learning the language need to understand. > But the current prohibition make me confused, may I am not a typical gopher. Why does it make you confused? On a 64-bit system, the types "int" and "int64" have the same representation. They are both 64-bit signed integers. Does it confuse you that Go rejects var v int = int64(1) ? If that does not confuse you, then the fact Go does not permit assigning from []Age to []int should not confuse you. It is the same kind of thing: in Go, different types are different. Ian -- 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.
