In the meantime, I've extended your AS/IS patch over here
<https://bugs.freepascal.org/view.php?id=33603> to create efficient code
for x86 platforms, although currently it only does a range check and
won't correctly handle enumerations with holes. If non-contiguous
enumerations are going to be allowed, we'll need to design an algorithm
that can cover these holes with the smallest number of Boolean conditions.
Gareth aka. Kit
On 05/07/2019 21:13, Ondrej Pokorny wrote:
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
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
