[fpc-devel] [Suggestion] Enumeration range-check intrinsic

[Michael Van Canneyt]

On Fri, 5 Jul 2019, Ondrej Pokorny wrote:

> On 05.07.2019 09:04, Michael Van Canneyt wrote:
>> In this, I would definitely exclude enumerateds that have explicitly 
>> assigned
>> values: str does not handle them, getenumename etc. also do not work:
>> They are in effect simply integer constants. (if I had my way I would
>> even remove them from the language).
>>
>> So using the above construct on such an enum can lead to a compiler 
>> error,
>> because the compiler cannot check anyway: better a clear error than 
>> undefined
>> behaviour.
>
> On the contrary, the compiler can check enums with holes with no problem 
> at all. They have valid low/end boundaries. And the holes in between are 
> valid values as well.

Eh ? Not in my book, if the compiler allows that it is simply wrong IMO.

An enumerated enumerates the allowed values: no holes allowed.

What you describe, I would name a range, not an enumeration.

> So there is no actual need or benefit to disable this feature for enums 
> with holes.

See above.

The way I read jonas' argument:

TMyEnum = (one, two=3,three);

A:=TMyEnum(1) ;

will pass unchallenged.

I don't see the point of allowing this. for me, "A" has an invalid value.

Note: 
This is my opinion, it may be at odds with what the compiler actually
implements :)

> +++
>
> Btw. why nobody commented on my latest suggestion in 
> https://lists.freepascal.org/pipermail/fpc-devel/2019-July/041499.html ?
> IMO this is a valid solution for both sides.

What part exactly ? The additional range check for a case in case of range
checking ? I don't see why you need it, since in case range checking is
enabled, the assignment of the variable should already have ensured that
there are only valid values in it. But I have no strong opinion on this.

As for (MyEnumType1Value is TMyEnumType2) : this is also a good suggestion.


Michael.