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

[Ondrej Pokorny]

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, even if they don't have names assigned. (E.g. the 
warnings in case-of are enabled for enums with holes as well!)

The 02.patch and 05.patch in 
https://bugs.freepascal.org/view.php?id=33603 handle enums with holes 
correctly. (Only the 03.patch disabled IS/AS for holes with enums in 
OBJFPC mode as a complementary feature, but I removed it consequently.)

See Jonas' answer about enums with holes:
https://lists.freepascal.org/pipermail/fpc-devel/2019-May/040868.html

Citation:
 > Yet, it still does not answer my question if the holes belong to the
 > valid enumeration values from the FPC point-of-view or not.

As far as range checking and undefined behaviour is concerned, they do.
I.e., you won't get undefined behaviour by assigning any value between
low(enum)..high(enum) to them.

+++

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

+++

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.

Ondrej