Clarifying: I'm not asking a question. However, the explanation is a
good one. It could form the basis for a FAQ answer.
On Sun, 2016-08-28 at 22:40 -0700, Ian Lance Taylor wrote:
> 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.
