Forwarded from marcov@stack.nl (Marco van de Voort):
A slight advantage of the delphi method is that it requires dirty syntax to do dirty things. That could be seen as a deterrent.
As a general principle, I agree -- though some (optional) warnings would also be fine. However, AIUI, what Markus want to do isn't actually dirty stuff, i.e. all type-safe.
Of course, that can be a problem -- as always if not carefully used. BTW, do you warn if taking the address (@) of a normal (non-object) variable on the stack?
Not this moment. But IMHO it should, though we would probably call it a "hint" (something that is not _always_ wrong).
Doesn't this apply to most warnings? E.g., comparing floating point numbers with = or <> is often wrong (due to inexactness), but not always (if you know what values they can have). And, of course, most dirty stuff can be right or wrong, and the compiler will never know ...
If the compiler can see that something is always wrong, it's usually better made an error, such as never assigning a function result (which is an error according to ISO even). (Even though it's not strictly always wrong, e.g. if you always leave the function with goto, Halt, etc., but then it's at least pointless to declare it as a function.)
Frank