[fpc-pascal] Incompleteness of current fix for #22860

JC Chu jcchu at acm.org
Thu Sep 13 16:16:32 CEST 2012

On Thu, Sep 13, 2012 at 4:17 PM, Jonas Maebe <jonas.maebe at 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

More information about the fpc-pascal mailing list