array of elements of various sybtypes

[Jonathan M Davis]

On Wednesday, January 26, 2011 15:07:09 spir wrote:
> On 01/26/2011 07:32 PM, Jonathan M Davis wrote:
> > On Wednesday, January 26, 2011 09:30:17 spir wrote:
> >> On 01/26/2011 06:27 PM, spir wrote:
> >>> Hello,
> >>> 
> >>> This fails:
> >>> 
> >>> class T0 {}
> >>> class T1 : T0 {}
> >>> class T2 : T0 {}
> >>> 
> >>> unittest {
> >>> auto t1 = new T1();
> >>> auto t2 = new T2();
> >>> T0[] ts = [t1, t2];
> >>> }
> >>> 
> >>> Error: cannot implicitly convert expression (t1) of type __trials__.T0
> >>> to __trials__.T2
> >>> Error: cannot implicitly convert expression ([(__error),t2]) of type
> >>> T2[] to T0[]
> >>> 
> >>> I guess it should be accepted due to explicite typing 'T0[]'. What do
> >>> you think? D first determines the type of the last element (always the
> >>> last one), here T2. Then, /ignoring/ the array's defined type, tries
> >>> to cast other elements to the same type T2. It should instead, I
> >>> guess, check all elements are compatible with the defined array type.
> >>> An additional enigma is why the failing element t1 is said to be of
> >>> supertype T0 --which is also correct-- while it retained t2's exact
> >>> type T2. ???
> >>> 
> >>> Anyway, is there a workaround?
> >> 
> >> PS: this works, but I would prefere a solution with all casting:
> >>       T0[] ts = [cast(T0)t1, cast(T0)t2];
> >> 
> >> I consider this issue a bug, at least when the array is explicitely
> >> typed. What do you think?
> > 
> > The problem is that the expression to the right of the assignment is
> > completely independent from the assignment. The expression results in
> > whatever type it results in, and _then_ it's assigned to the variable.
> > In this case, its a variable declaration as opposed to an assignment, so
> > it's initializing the variable instead of assigning to it, but from the
> > perspective of the expression, there's no difference. It's just like how
> > you can't overload functions on return type.
> 
> Yop, had this problem a could of times as well.
> 
> >How the result of the function is used is irrelevant to evaluating the
> >
> > function. In this case, how the result of the expression is used is
> > irrelevant to evaluating it. It would actually probably be a pretty big
> > language change to try and make it otherwise, and I'm not sure what all
> > the ramifications are. I can see why you'd want it, but I really don't
> > expect it to happen. Walter just wouldn't go for it. So, it's not a bug
> > at all.
> 
> Right, I understand the point of evaluating the expression independantly of
> its use in a second phase.
> But then, how are we supposed to have such arrays? Note that:
> 	T0[] ts;
> 	ts = [t1, t2];
> fails exactly the same way (and for the same reason). How can I feed ts?

I believe that it's supposed to take the common type of t1 and t2 and make the 
result an array of that type. So, assuming that the common type is T0, then it 
should work. However, it's not currently implemented that way. You could always 
create a bug report so that it doesn't get lost (assuming that no such report 
already exists).

- Jonathan M Davis