Yes, it should. The bottomline is that cases treated as overloadable must not be defined by the default interpretation, because the overloaded interpretation will always take precedence. This is probably why the ld.typ = orddef case is not handled by either isbinaryoperatoroverloadable() or its unary counterpart. (But it’s really not true that ordinal types always make trouble—think of * as (Char, Integer) → string, for example.)
Speaking of unary operators… I did not change isunaryoperatoroverloadable() to allow NOT to be defined on Double and enumeration types. I think NOT should be allowed on all types except ordinals (which include Booleans). Our terminology seems a bit inconsistent, too, don’t you think? PChar and PWideChar correspond to pointerdef, but behaves like strings---namely they can be manipulated and compared using operators +, =, <>, <, <=, >, and >= with another string-like entity (- doesn’t seem to belong there). The original implementation for the ld.typ = pointerdef case already guarantees that both the LHS and the RHS are string-like, so it remains only to add a limit on the operator so that only those mentioned above are forbidden. The thing that worries me is that I’m not sure if the default interpretation depends on the compilation mode being used. If that is the case maybe the rules will become even more complicated. On Tue, Jul 3, 2012 at 3:51 PM, Sven Barth <pascaldra...@googlemail.com> wrote: > 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). -- Best regards, JC Chu _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
