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

[JC Chu]

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 <pascaldragon at 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