[fpc-devel] Dangerous optimization in CASE..OF

[Michael Van Canneyt]

On Sun, 2 Jul 2017, Martok wrote:

> Am 02.07.2017 um 10:40 schrieb Michael Van Canneyt:
>> These cases are without exception covered by the " unchecked (aka explicit)
>> typecast," part of Jonas's statement. Including Read(File).
>
> Aye, that was kinda my point ;)
> It is really hard to write code that interacts with the outside world without
> having a validation problem.

No it is not, see my sample code. You're responsible for making sure that
the values that come from the outside world are valid. The compiler cannot
do that for you.

> If the validation code then breaks because the compiler thinks it's clever...

No, the compiler assumes it, and it alone, controls the possible values.
It acts on that assumption. That is why you have an enum to begin with.

Else you could and should use an integer and a set of constants.


> Am 02.07.2017 um 10:29 schrieb Michael Van Canneyt:
>> GetEnumName from typinfo will already do this for you.
>> We could add an additional function that just returns true or false.
>> Something as
>> function ValueInEnumRange(TypeInfo : PTypeInfo; AValue : Integer) : boolean;
>
> Enum Typeinfo is horribly broken in so many ways except for the one simple case
> needed for published properties, it definitely cannot be used in its current form.

Without a decent explanation, this is a very gratuitous statement, which we
will simply discard as not worthy of a reaction.

So please explain.

Michael.