On 12.05.2019 18:56, Jonas Maebe wrote:
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.
Very good, thank you. IMO this should be clearly documented to avoid
confusion.
And if they are valid they should not cause any runtime errors:
program Project1;
{$mode objfpc}
type
TMyEnum = (two=2, five=5);
var
E: TMyEnum;
begin
E := TMyEnum(3);
Writeln(E); // RunError (107)
end.
(From the above example one would say they are not valid.)
Furthermore I strongly disagree with your (2) statement. On the
contrary, if there are all explicitly defined cases covered and there
is an else statement (like in the TestRanges program above), a
warning about the unnecessary case statement is very needed because
it is an "implementation detail" of the compiler if the else block
will ever be executed or not (AFAIR you supported this).
The TestRanges program is not about an implementation detail, but
about undefined behaviour. Those are two completely different things.
There was a misunderstanding. I thought you meant with "implicit" values
the "implicit default values" (=0):
program Project1;
{$mode objfpc}
type
TMyEnum = (two=2, five=5);
TMyObject = class
E: TMyEnum;
end;
var
O: TMyObject;
begin
O := TMyObject.Create;
Writeln(Ord(O.E)); // R has an implicit default valuethat is invalid
ReadLn;
end.
But you meant the implicit valid values (the holes). Now it's clear.
Best
Ondrej
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
