On 11/07/2019 13:07, Michael Van Canneyt wrote:
There is no "disagreement". just doubt as to what the right approach is.
If the compiler assumes that an enumerated always contains a valid value,
then the logical consequence is that the above "is" always evaluates to
true. In that case it makes sense to downright forbid the construct,
as it
only makes sense if MyEnumValue is another ordinal type.
The case of bitpacked values and variant records shows that the language
allows for cases where this assumption is maybe not correct. From this
point
of view, the above construct is a valid check and should not be optimized
away.
It now depends on your point of view what road to take.
Michael.
Well, the patch ("AS-IS-enum-10.patch") was made on the assumption that
"MyEnum is TMyEnum" will do a range check and return False if it's out
of bounds.
Outside of typecasting, there isn't a reliable way to check if an enum
contains a valid value, which leads to the problem of reading an enum
from an external source that may be tampered or corrupted. I had the
impression that "as" and "is" would be a reliable sanity check to see if
the enum is in bounds.
For my personal point of view, I would like these operators to be the
exception to the rule of the compiler assuming an enum always contains a
valid value, and above all, the documentation improved for "case" that
advises the programmer to use the operators if they are using
enumerations and there's a chance the input may be invalid. Whatever
decision is made though, I do think there should be a warning in the
documentation and a suggested workaround just so we don't keep getting
bug reports.
I'm not on the core team though, so the final decision ultimately
doesn't rest on me, but for what it's worth, I would like "MyEnum is
TMyEnum" to not assume the answer is True and to actually perform an
explicit check. However, there is an argument to be made for both
approaches.
Gareth aka. Kit
---
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
