[fpc-pascal] Custom operators for non-record types

[Sven Barth]

Am 03.07.2012 02:51, schrieb JC Chu:
> isbinaryoperatoroverloadable() is called once.  It first calls
> internal_check() with the default (LHS, RHS) order.  internal_check()
> accepts or rejects the pair only if it recognizes the pair.  Only if
> (LHS, RHS) is not recognized, will internal_check() be called again
> with the order reversed.  If neither (LHS, RHS) nor (RHS, LHS) is
> recognized, isbinaryoperatoroverloadable() defaults to False.

Yes, I mean internal_check. Sorry. I hadn't the source available when I 
wrote you yesterday.

> (Besides, commutativity is a semantic property which relies on the
> user implementation and cannot be deduced at compile time.)

For commutativity regarding the implementation you are right, but I was 
talking about commutativity regarding the possibility to overload. E.g. 
you should be able to overload "and" no matter whether it's argument 
types are "(String, LongInt)" or "(LongInt, String)".

> Rejection rules are used to prevent conflicts with the default
> interpretation.  The original implementation, however, rejects
> overloads based solely on the operand type combination, not taking
> into consideration the operator being used.  For the
> string-as-the-first-operand case, this resulted in, say, * as a
> function on (string, PChar) being rejected, which is legal.  What I
> did with it is restrict the operand to +, =,<>,<,<=,>, and>=
> (and, of course, removing the limits on the second operand being an
> enumeration).
 >
> For some operators, only one-sided protection is necessary.  For
> example, IN must not be overloaded as a function on (<enumeration>,
> <set>).
>

Agreed so far. :)

> For some operators, the set of accepted operand type pairs should be
> symmetric, and thus so should its complement, the set of rejected
> pairs.  If acceptance and rejection rules are inconsistent, rejection
> becomes sensitive to the order of operands.  For example, I didn’t
> change pointer-as-the-first-operand case to allow for (PChar, string)
> overloads, so * as a function on (PChar, string), despite legal, still
> gets rejected.
>
> That is to say, the rules in internal_check() are not yet exhaustive.

So in the end "* (PChar, String)" should be allowed as well out of 
consistency, shouldn't it?

Nevertheless for pointers one needs to be careful, as I don't know 
exactly how far internal pointer arithmetic operators are available 
(AFAIK at least "+" and maybe "-" exist).

Regards,
Sven