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 :)
+++
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 ? 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. But I have no strong opinion on this.
As for (MyEnumType1Value is TMyEnumType2) : this is also a good suggestion.
Michael.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
