[fpc-devel] Dangerous optimization in CASE..OF

[Martok]

I'll start at the end.

>> There has to be a reason why everybody else chose Low-Level enums, except that
>> it is far simpler to implement, right?
>
> I don't know, but I still don't understand why on Earth you would want
> them in a strongly typed language.
I see them as extremely useful as enums with explicit assignments, and indeed
not so much with "automatic" enums.
Explicit Enums then become a way to have assignment-safe (not typesafe in the
true sense of the word) constants - the compiler can tell me that trying to
assign a SignatureAlgorithm name to a CipherAlgorithm field is wrong, for
example. {$SCOPEDENUMS} can also improve readability - I have a Canon EDSDK
import that only really works because of that constellation.
Or take the gazillion of uint constants for OpenGL, grouping them in a type by
what they do can show when I confuse similar-sounding constants.

I'll reply to your code examples in a second message because I think you just
uncovered another bug.

> Well, unless of course consider having base types that are not a> multiple of 8 bits (I don't see any definition of what can constitute a> base
type on the Delphi page you linked). Then you would also have to> add overflow
checking for non-multiple-of-byte-sized types. And in this> case, you would
still need to support out-of-range values up to whatever> fits in the number of
bits reserved for said base type, but at least it> would make bitpacking
possible. OTOH, in terms of safety or simplicity> of implementation, little or
nothing would be gained.
I don't think they have bitpacking?
Base type for enums is Byte, Word, Cardinal depending on $Z.
"When you use numeric or character constants to define a subrange, the base type
is the smallest integer or character type that contains the specified range."
and I would assume the enum type for subranges over enums.

And yes, subranges are a bit useless outside of their declarative meaning and in
set construction.
>From the manuals it looks like they tried changing that in between TP5 and TP7
(probably because of the Pascal standardisation?) but went back to the old
relaxed solution for Delphi.

Proposal:
Everything stays as it is for 'automatic' enums.
'Explicit' enums internally have the full range of their base type
(get_min/max_value, getrange return the base type's values), except for two
functions: the Low() and High() intrinsics continue to return the first/last
declared element.

I believe this is entirely in the previously undefined part of the language. It
makes no change to automatic enums and aligns explicit enums with Delphi. Having
the range functions like that means we don't have to touch any optimizer code at
all - it gets the correct bounds. Same for range checking code.
Subranges continue to be strict (as the "convex hull" of the enumeration's
declared values, but also covering unnamed values in between), so nothing
changes for arrays or bitpacked records.

How about that?

Martok