array of elements of various sybtypes

[spir]

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?

Denis
-- 
_________________
vita es estrany
spir.wikidot.com