It seems: string me = (typeid(bars[1])).toString; if(endsWith(me, "Foos")) writeln(to!(Foos)(bars[1]).val);
I see there is another post where somebody has asked if they can use cast(typeof(typeid(bars[1]))).val, and it was explained that the compiler won't know typeid until after compilation but it needs typeof at compilation, so that doesn't work. So it seems a string comparison is required (hopefully I am wrong on this). Thus it seems a choice of three or four reasonably off choices all because dmd is missing a keyword (maybe "derived") that would act like the keyword super but in the other direction; if the compiler can sus out the super from the derived at compile time then it necessarily knows what the derived is.
The options are accept property syntax and add an interface, which means introducing extraneous copies of functions and oddly duplicate variable names that invite all manner of bugs.
Define variables which are to be used from the derived class in the base class and spend hours scratching your head about where the variable you are looking at in the derived class has been declared, then remembering and spending ages flipping from derived to base class to see what is going on.
Perform string operations to discover what the actual derived type is and then cast the base to its initialized type.
Wouldn't it be easier to simply write bars[1].derived.val and let the compiler look to and accept val if it is declared in the derived class, else gracefully accept val if it is only declared in the base class?
