Jonas,

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).

Forbidding all of those enumeration-related overloads, however, will undo much of what the relaxation patch was intended for.

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.

Since this weakening happens only within enumeration definitions, I think it should be treated specifically.

JC Chu wrote on Thu, 13 Sep 2012:

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.

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

Jonas Maebe wrote

I think one of the prime requirements to get readable code is that a compilable expression always means the same.

Other forms of polymorphism can also lead to violations of this requirement. Basically I think it should be left to the user to decide when something is appropriate.

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.

It does look ugly at first but I think it is clear (to both writers and readers) that no overloaded operators can be in effect within enumeration type declarations because 1) most obviously the type has not been fully defined and 2) constant expressions do not accept overloaded operators.

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.

If something like “enumeration + integer” appears in regular code, that “+” can _only_ be user-defined because it is undefined in the default interpretation---there’s no ambiguity to the reader unless the writer use operator overloading irresponsibly.