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

[Michael Van Canneyt]

On Sun, 16 Jul 2017, Ondrej Pokorny wrote:

> On 15.07.2017 21:39, Jonas Maebe wrote:
>> On 15/07/17 21:33, lazarus at kluug.net wrote:
>>> Am Sa., Jul. 15, 2017 21:07 schrieb Jonas Maebe <jonas at freepascal.org>:
>>>
>>>     I have said from the start that it is possible to store invalid values
>>>     in variables through the use of a.o. pointers (which is what the class
>>>     zeroing does), explicit typecasts and assembly.
>>> 
>>> In this case you must not restrict us to work with invalid values in a 
>>> deterministic way.
>> 
>> You can if you always use explicit typecasts to different types and access 
>> everything through pointers and assembly. But then the question is why you 
>> want to use a restrictive type in the first place.
>> 
>> Either you declare a type as only holding a limited set of data when valid 
>> and assume it behaves as such, or you don't. A mixture is the worst of both 
>> worlds: no type safety and unexpected behaviour when something else assumes 
>> the type declaration actually means what is written.
>
> The problem is that you yourself force us to the mixture that "is the worst 
> of both worlds".
>
> On the one hand you say that the compiler can generate invalid values and on 
> the other hand you say that the compiler can assume the enum holds only valid 
> values. For now, there is absolutely no range checking and type safety for 
> enums - so you can't use it as an argument.

You are missing the point of an enumerated.

The whole point of using an enumerated is that range checking 
*is not necessary*, because the values are 'by definition' correct.

If the compiler cannot assume this, you're just using an integer with 
some named values.  Hardly worth a separate type.

Michael.