On 15/07/17 21:34, Martok wrote:
This will never generate a range check error, because the type
information states that a tsubenum2 value is always a valid tsubenum
value. Array indexing a special case of this, as semantically the
expression you use to index the array is first assigned to the range
type of the array.
I would assume that this is something that "someone with a solid
knowledge of the language" would expect.
Probably. Subranges are after all explicit subsets of something. But let's not
digress, right? That's not related to the topic at hand.
I mentioned it because we use exactly the same reasoning for subrange
types as the one you consider completely unacceptable for enumeration
types. Subrange types also consider only part of bit patterns that can
be represented in their allotted memory space as valid, and any other
value stored in there results in undefined behaviour. The case-statement
optimisation happens for those types in exactly the same way, even
though you can also force invalid values into them.
And you also have subranges of enum types. Can any assumptions made
about those in your opinion?
But I finally understand where the disconnect comes from. I have always
thought of enums as more or less equivalents of subrange types, simply
with an optional name for the values. You, and indeed the Pascal
standards, treat them differently.
Does that mean that you would consider the same transformation of a
case-statement when using a subrange type as correct? And that putting a
value outside the range of a subrange into such a variable as a
programmer error? (as opposed to doing the same with a non-subrange enum
type?)
In any case, we have mode ISO for being extra-ISO-compatible - there are some
significant differences between Borland Pascal and ISO/IEC already.
That is true. But I consider this behaviour a fundamental part of a
type-safe language like Pascal. You want to make the language less
strictly typed in order to have defined behaviour when using code that
puts invalid values into variables.
Note that FPC doesn't accept this code in mode (Obj)FPC, but correctly does so
in DELPHI, with the same result as Delphi.
Maybe we can indeed change it in TP/Delphi modes, although I still think
it is defeats the purpose of using enums in the first place.
And it would also require us to conditionalise every future optimisation
based on type, in particular separating the treatment of enums from that
of integers. That's a lot of (future) work and care to deal with what I
still consider to be bad programming.
Jonas
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
