runtime type and that bizarre "is()"

bearophile bearophileHUGS at
Sun Nov 14 04:11:18 PST 2010


Only partial answers, other answers left to other people.

> Is there a way to check the runtime type of an element? Meaning, for instance, process differently according to the actual type in a hierarchy?

You may use a cast(). If it return null then it's not castable.

> Also, I would like to ask about "is()". I don't understand its logics and uses, even after reading TDPL pages about it. Seems uselessly complicated and unintuitive. 

Lot of people think is() is indeed one of the less intuitive and easy to use parts of the language. Several people have suggested possible replacements, but not much has changed.

> For instance, in the above cases, why do I need is() at all? Why not just "typeof(c) == C1"? or even better "typeof(c) is C1"?

Or better "c isa C1".
I and other people have suggested that is(...) is not so nice, but I think for the compiler is simpler to keep the type world more separated from the world of expressions... And keeping the compiler simpler wins.

> By the way, why is "is(typeof(c) is C1)" refused by the compiler?

Maybe because the "is" syntax is newer, and maybe to avoid using is inside is.

> (For instance, 2 structs or classes that happen to define identically named and typed fields are _not_ the same, unique, type.)

See on the Wikipedia the difference between nominative type systems and structural type systems.


More information about the Digitalmars-d-learn mailing list