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 _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
