On Sun, Aug 28, 2016 at 12:41 AM, Dan Kortschak
<dan.kortsc...@adelaide.edu.au> wrote:
>
> This would have been a significantly shorter thread if there had been a
> clear explanation of the motivation behind slice conversion restrictions
> early. This could have been after about the second (certainly by fourth)
> post from TL where it became clear that he was asking about motivation
> rather than mechanics (the initial post was ambiguous).
I apologize for a pedantic response, but there are no slice conversion
restrictions. I agree that it's a little confusing, because
conversions are permitted among numeric types (and there are a couple
of other value-changing conversions, like between string and []byte).
As soon as you get into composite types (slices, arrays, structs,
maps, channels, functions) the rule is fairly simple: conversions are
permitted if the types have identical underlying types.
So I think the question you are asking (I honestly don't know what
question TL is asking) is: if T1 and T2 are both defined to have
identical underlying types, then why not permit conversions between
composites involving T1 and T2? Why not permit converting []T1 to
[]T2? Why not permit converting func(T1) T2 to func(T2) T1? Why not
permit converting struct { f1 T1; f2 T2 } to struct { f1 T2; f2 T1}?
In Go, types are closely tied to methods. Every type has a method
set. Another way of stating the rule for conversions between
composite types is that you can change the method set of the type
being converted (by converting to a different type, with different
methods, that has the same underlying type) but you can't change the
method set of elements of the composite.
As to why Go has that restriction, I would say that it is simply
because 1) it is conservative--people are unlikely to get into
accidental trouble; 2) real programs rarely seem to need to do this
kind of conversion.
I want to be clear here: real program do often want to do a different
kind of conversion: between interfaces with methods with different
result types, to support covariant and contravariant types. That is
not what we are talking about here. That would be difficult to
implement for reasons that have been discussed elsewhere. The
question I am addressing is why Go doesn't permit conversions between
composite types built out of non-identical types with the same
underlying type. I am asserting that that is not common in real
programs.
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.
