[fpc-devel] [Suggestion] Enumeration range-check intrinsic

[Martok]

> In Delphi's type system (and in C, C++, and C#), the valid values for an
> enum are always all values that fit within its storage size, and that
> storage size is fixed.
> 
> In FPC's type system (and in Ada and Java), the valid values for an an
> enum are only the values between the lowest and the highest declared
> enum element (in Java it's even more strict, in that when you have
> "enums with holes", the holes are also invalid), regardless of the
> storage size. Moreover, this storage size can vary depending on whether
> or not the item is in bitpacked storage.

Side note: if this was done 100% consistently (and it does make sense!), the
PACKENUM directive would be completely useless. There is no point in being able
to specify the storage size of an enum when it can be and is ignored at will.


C# and C++ do the same with explicitly sized enumerations. Who would I have to
bribe to get that in FPC?

{$mode objfpc}
type
  tmyenum : Byte = (ea, eb, ec);

That would solve literally all problems we ever discussed:
 - the "scoped constant" concept is obvious when used
 - for bitpacking purposes, the bitsize is that of the explicit ordinal
 - therefore, any same-size cast (API return, file io, network io) is valid
 - {$Mode TP} and {$Mode Delphi} would treat all enum declarations as sized
enumerations of whatever $Z is set to at declaration time, fixing the "same
syntax but invisibly different result" portability issue
 - both type concepts would be consistently handled in the same type system
 - whenever that syntax is not used, all existing optimizations are valid
 - when it is used, others may be chosen
 - the case label checks would also catch any problems we don't yet see


Anything else (including the intrinsics this is about) is just a hacky
workaround to the difference Jonas summarised above, IMHO.

-- 
Regards,
Martok