array of elements of various sybtypes

Steven Schveighoffer schveiguy at
Wed Jan 26 18:54:47 PST 2011

On Wed, 26 Jan 2011 18:33:45 -0500, spir <denis.spir at> wrote:

> On 01/26/2011 07:23 PM, Steven Schveighoffer wrote:
>> On Wed, 26 Jan 2011 12:27:37 -0500, spir <denis.spir at> 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?
>> auto ts = cast(T0[])[t1, t2];
> Nope, refused for the same reason (tried to construct [t1,t2] before  
> casting it).

Hm.. maybe that only works on array literals with all literal elements.  I  
expected the cast to affect the type the compiler is expecting.

For example, this works:

cast(ubyte[])[1,2]; // without cast typed as int[]

I believe there should be a way to tell the array literal "this is the  
type you should be."  If that's not possible, then it needs to be added.   
If it's expected the cast should work, then I'd file a bug against it.


More information about the Digitalmars-d-learn mailing list