On Thu, Sep 13, 2012 at 4:17 PM, Jonas Maebe <jonas.ma...@elis.ugent.be> 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. -- Best regards, JC Chu _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
