On 05.07.2019 16:51, Pierre Muller wrote:
This means that using pred() or succ() intrinsics on enumerated types with
holes will generate a Compile Time Error.
To be consistent, I would propose that we also generate
a Compile Time Error if 'is' or 'as' keyword is used on such a type,
unless there is a code that really check that the value is not in
one of the holes ...
I have to strongly disagree here. We need the IS/AS operators to prevent
undefined behavior. And if undefined behavior is only outside the
low/high bounds of the enumeration values and not within the holes -
then the IS/AS that checks only the bounds is very consequent indeed.
It's also consequent with the case-of statement for an enum with holes.
(See the thread I linked before.)
Ondrej
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
