On Thu, 11 Jul 2019, J. Gareth Moreton wrote:
On 11/07/2019 11:52, Ondrej Pokorny wrote:
BTW, your note in the issue report is very misleading:
https://bugs.freepascal.org/view.php?id=33603#c117162.
> The idea behind "is" and "as" is that they are the sole exception to
the rule and will return False and raise an error respectively if the
enum is out of bounds.
IS/AS are not an exception of the rule - after a long discussion we
settled down that if IS/AS is applied on a value of the same
enumeration type:
var
MyEnumValue: TEnumValue;
begin
if MyEnumValue is TEnumValue then
// ...
end;
the compiler will expect that the result is always true. (It doesn't
have to check for invalid values.)
Who is "we" in this case? I was under the impression that is/as could be
used to check if the enumeration was valid or not, as a means to check
if the enueration contained a valid value or not so as to avoid problems
with case blocks raising access violations. I guess we've hit
disagreements again.
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.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
