Frank Heckenbach wrote:
We should not. According to BP (the only documented reference I have about type-casts at all), there are two kinds of type-casts: Variable type-casts (which require variables, or rather "lvalues" and cast to types of the same size -- as for lvalues the size is well-defined), and value type-casts which apply to ordinal types (and pointers in MP) and which conserve ordinal values (or addresses).
I thing that BP really mixed different things together. I would say that there are two kinds of casts: raw cast, which just interpret storage (bit pattern) as a different type and conversions, which may do some non-trivial computation.
Additionaly, cast may silently "do the work", or they may serve as assertions that the value "really" is of different type.
Raw casts typically do not signal errors, still one could signal them for invalid or out of range values.
I see a few different uses of casts:
1) for low-level programming, here we want raw cast and it should not matter if the value converted is variable or constant. Actually, the only bad case seem to be set constants, since we can extend/truncate integers to desired size and other constansts have well defined size. So forbiding all constansts (even typed!) seem to harsh for me.
2) Our current signed/unsigned problems clearly show need for explicit conversions in arithmetic expressions. It make some sense to allow such conversions also for sets (but I do not insists).
3) Cast as type assertions are frequently used in OOP, where one wants to treat an object as object of different class (handled by `as')