JC Chu wrote on Thu, 13 Sep 2012:
Regarding bug #22860 on the inability to define enumeration members using expressions containing previously defined members of the same type, the current fix does not provide a complete solution. The current fix won’t allow for valid declarations such as TYPE TMyEnum = (meA, meB = 1 + meA) and TYPE TMyEnum = (meA, meB = meA xor meA).
Thanks, I'll fix that.
Forbidding all of those enumeration-related overloads, however, will undo much of what the relaxation patch was intended for.
As I think I mentioned in the original thread, I was never a very big fan of that relaxation because of unforeseen side effects.
The compiler should expect an integer-typed constant expression after ‘=’, with a weakened type checking that takes as Ord(x) each enumeration member x in the expression, where x must belong to the enumeration type being declared, and must appear before the member it’s used to define.
I think one of the prime requirements to get readable code is that a compilable expression always means the same. Changing the meaning of "enum + int" or vice versa depending on whether you're in a type definition or in regular code following an overloaded operator goes completely against that principle. Of course, a programmer can circumvent that by defining a particular operator in multiple units with different meanings, but at least as far as natively supported operators are concerned we can ensure that this principle is respected. Jonas _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
