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 _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel