Re: Custom operators for non-record types
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
> For some operators, only one-sided protection is necessary. For
> example, IN must not be overloaded as a function on (<enumeration>,
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).
fpc-pascal maillist - fpc-pascal@...