[perl #113834] overloading fallback for + and += is broken

This issue still needs clarification.  What was actually wrong
with the behaviour of overload-1.18?

Quoting the commit message of f041cf0f9c6469c41de8b73d5f7b426710c3ff8b:
> At the very beginning of Perl_amagic_call, if the flag AMGf_noleft is
> not passed, we first try to look up the overload method corresponding
> to the assignment operator, then the normal one if fallback is
> authorized. However, if this fails, when trying later to find
> overload magic with the arguments swapped (if AMGf_noright is not
> passed), this procedure was not used and we looked up directly the base
> operation from which the assignment operator might be derived.
> As a consequence of what an operator like += might have looked
> autogenerated even when fallback=>0 was passed.

Is it wrong to directly look at the base operation, once the
rhs operand may handle the overloading?  The rhs operand must
not be modified and thus can not act as as the object being
assigned to.  Intentionally, assignment operator methods have
been defined to only overload assignments to an object, not
assignments from an object.

Therefore the base operation may come into play not for lack of
an optional assignment operator method but for simple semantic
reasons.  Fallback, on the other hand, has to do with the
treatment of missing methods.  It tells whether missing methods
may be replaced by something else and, if so, by what.  So far,
it only covers operators that can be overloaded separately.

A more radical interpretation of the "fallback=>0" setting,
preventing "foo += bar" being handled by bar's "+" operator,
say, would only make sense with a larger interface that had an
own method for the "+= bar" case.  Otherwise, "fallback=>0"
would not prevent falling back but would prevent evaluating
the expression at all.  There would be nothing to not fall
back from.  A class wanting to make "+= bar" legal could
not opt out of fallbacks in general.

In short, what f041cf0f9c6469c41 set out to change does not
look like a bug to me.  It may be different from what some
people expect.  They do have a point in that the documentation
might be more explicit about what exactly constitutes a
fallback.

Another point that remains unsolved if this change is
rejected is the use case that actually wanted a way to
override assignment operators in the class of the rhs operand.

The overload interface could be extended to allow that.
Of course, it would need different symbols from those
that are already in use.  Maybe mirror images of the
ordinary assignment operators such as "=+", "=-" etc. would
do, as a mnemonic for the fact that these operators are
looked at "from the other side".  Classes not wanting to
catch or define these should not be forced to allow
fallbacks, however, or we would create a portability problem.
There is also the risk of typos going unnoticed.

-Martin

---
via perlbug:  queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=113834

• [perl #113834] overloading fallback for + and += is broken by Martin Hasch via RT
• Re: [perl #113834] overloading fallback for + and += is broken by Jesse Luehrs