On 05.07.2019 09:57, Michael Van Canneyt wrote:
On Fri, 5 Jul 2019, Ondrej Pokorny wrote:
On 05.07.2019 09:04, Michael Van Canneyt wrote:
In this, I would definitely exclude enumerateds that have explicitly
assigned
values: str does not handle them, getenumename etc. also do not work:
They are in effect simply integer constants. (if I had my way I would
even remove them from the language).
So using the above construct on such an enum can lead to a compiler
error,
because the compiler cannot check anyway: better a clear error than
undefined
behaviour.
On the contrary, the compiler can check enums with holes with no
problem at all. They have valid low/end boundaries. And the holes in
between are valid values as well.
Eh ? Not in my book, if the compiler allows that it is simply wrong IMO.
An enumerated enumerates the allowed values: no holes allowed.
What you describe, I would name a range, not an enumeration.
So there is no actual need or benefit to disable this feature for
enums with holes.
See above.
The way I read jonas' argument:
TMyEnum = (one, two=3,three);
A:=TMyEnum(1) ;
will pass unchallenged.
I don't see the point of allowing this. for me, "A" has an invalid value.
Note: This is my opinion, it may be at odds with what the compiler
actually
implements :)
Read:
http://docwiki.embarcadero.com/RADStudio/Rio/en/Simple_Types_(Delphi)#Enumerated_Types_with_Explicitly_Assigned_Ordinality
+++
Btw. why nobody commented on my latest suggestion in
https://lists.freepascal.org/pipermail/fpc-devel/2019-July/041499.html ?
IMO this is a valid solution for both sides.
What part exactly ? The additional range check for a case in case of
range checking ?
Yes.
I don't see why you need it, since in case range checking is enabled,
the assignment of the variable should already have ensured that there
are only valid values in it.
The compiler can never catch all kinds of assignments and do range
checking on them (e.g. FillChar, Read, pointer-writes, etc. etc.). So a
range check when accessing a value is needed.
It's the same reasons FPC has fpc_check_object and falls into the same
philosophy.
If I take your statement "in case range checking is enabled, the
assignment of the variable should already have ensured that there are
only valid values in it." to the extreme, it implies that the creation
of an object with a subrange value always ends up with a range check error:
program Project1;
type
TMyClass = class
private
FSubRange: 2..4;
end;
TMyRecord = record
SubRange: 2..4;
end;
PMyRecord = ^TMyRecord;
var
C: TMyClass;
R: PMyRecord;
begin
C := TMyClass.Create; // << range check error here
R := AllocMem(SizeOf(TMyRecord)); // << range check error here
end.
Ondrej
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
