> 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.
> but plain comparisons are removed at compile-time:*With* a warning. Two, > actually. >> However, FPC does not have the luxury of being the first to define and >> implement >> a new language (well, except for $mode FPC and ObjFPC). There is precedent. > > At least the precedent in ISO Pascal > (http://www.standardpascal.org/iso7185rules.html) is that you cannot > convert anything else to an enum, and hence an enum by design always > contains a value that is valid for that type (unless you did not > initialise it all, in which case the result is obviously undefined as well). I know this website, turns out that's not quite what ISO7185 says. The ISO is awfully unspecific about what you can or cannot do with enums. They simply define enumerated types as defining a set of constants with values 0,1,2 etc., and later the compatibility-rules you cite below. But even if we take the web version: """Enumerated types are fundamentally different from integer and subrange types in the fact that they cannot be freely converted to and from each other.""" 'fundamentally different from [...] subrange types' - what I said above. 'cannot be freely converted to and from *each other*' - what they mean by that is that type y = (red, green, blue); type day = (mon, tue, wed, thur, fri, sat, sun); var color: y; begin color:= fri; end. will not work. I don't think anyone would want that ;-) In any case, we have mode ISO for being extra-ISO-compatible - there are some significant differences between Borland Pascal and ISO/IEC already. Probably that mode should also receive the "non-bindable" limitation you cite from IEC10206. <off-topic>I just noticed: case..else should be a syntax error there, it doesn't exist in ISO7185 and should be case..otherwise in IEC10206 - where it is technically mandatory, because a non-matching argument is a dynamic-violation (RTE).</off-topic> We also have modes TP and Delphi, and at least there it is *not* an error to have an unnamed value in a variable, because (spoken in terms of the ISO) the ordinal-type of an enumerated-type *is* the base type, not a (potentially non-consecutive) subrange. I've quoted the relevant parts of the language references multiple times already. Low/High (and the compiler-internal analogue of them - cf. function getrange() in FPC) produce the first/last element, but that's it - for example Pred/Succ may produce unnamed elements. type TT = (a=2,b,c=7,d,e); // defines constants of type TT for 2,3,7,8,9 {$R+} var t: TT; begin t:= b; t:= succ(t); Writeln(ord(t)); // writes '4' end. Note that FPC doesn't accept this code in mode (Obj)FPC, but correctly does so in DELPHI, with the same result as Delphi. Added after Ondrej's message 20:52: Borland appears to have taken the route of what he called a 'LOW-LEVEL enumeration' from the very beginning. Martok _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
