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, even if they don't have names assigned. (E.g. the
warnings in case-of are enabled for enums with holes as well!)
The 02.patch and 05.patch in
https://bugs.freepascal.org/view.php?id=33603 handle enums with holes
correctly. (Only the 03.patch disabled IS/AS for holes with enums in
OBJFPC mode as a complementary feature, but I removed it consequently.)
See Jonas' answer about enums with holes:
https://lists.freepascal.org/pipermail/fpc-devel/2019-May/040868.html
Citation:
> Yet, it still does not answer my question if the holes belong to the
> valid enumeration values from the FPC point-of-view or not.
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.
+++
So there is no actual need or benefit to disable this feature for enums
with holes.
+++
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.
Ondrej
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
