overload: Synthesizing ne from not(eq)

[leonerd]

The use overload pragma has the ability to guess how to behave for operators that you didn't explicitly define, if you provided certain other ones. For example, if you just provide a cmp operator, it can use that to provide all the other 6 string comparisons:

use v5.40;
package LooksLikeAnOrange {
  use overload 
    fallback => 1,       
    cmp => sub ($this, $that, $) { return "orange" cmp $that; };
  sub new ($) { bless [], __PACKAGE__ }
}
say "Same" if LooksLikeAnOrange->new eq "orange";
say "Not different" unless LooksLikeAnOrange->new ne "orange";

## Outputs:
# Same
# Not different

That's useful.

I'm currently looking at the overload logic for other reasons, and I thought I recalled that it can generate an ne operator by inverting the sense of a eq operator, but it appears it can't:

use v5.40;
package LooksLikeAnOrange {
  use overload 
    fallback => 1,     
    eq => sub ($this, $that, $) { return "orange" eq $that; };
  sub new ($) { bless [], __PACKAGE__ }
}
say "Same" if LooksLikeAnOrange->new eq "orange";
say "Not different" unless LooksLikeAnOrange->new ne "orange";

## Outputs
# Same

It should have also printed "Not different" here, but it didn't, because the ne operator didn't fall back to using eq and inverting the result. Instead it stringified the object reference and then used plain ne logic.

I wonder - should it?

I ask specifically because, in the course of implementing operator overloading as part of PPC0030, it occurs to me that even if people provide overloaded implementations of equ, they are unlikely to want to write another one for neu. It ought to be easily possible to have the overload mechanism provide one by just invoking the not-inverted one and invert the result.

And of course, all the same arguments can be made for the numerical versions of these operators.

This would be especially useful because in the realm of people creating custom object types with custom overloaded operators, it's not always possible to put those objects into total orderings. There are many mathematical structures whose members can be compared for equality without being put into an order, so it would make sense for classes implementing those to provide an eq or equ without providing cmp. It would be useful if the ne or neu operators could then do the right thing even in the absence of that cmp.

[skington]

The documentation for overload suggests that fallback => 1 is bad, and you should just not specify fallback at all. (If I omit the fallback => 1 bit I get the same results.) You need to explicitly say fallback => 0 to turn this stuff off.

So maybe the API should be to say e.g.

  use overload
    autogenerate => ['ne'],
    eq => sub ($this, $that, $) { return "orange" eq $that };

if you wanted to opt in to new ways of autogenerating missing methods?

And maybe you could also say e.g.

  use overload
    autogenerate => [':v5.40', 'ne'],
     ...;

if you wanted to explicitly say "do all the standard autogenerations plus this one".

[Grinnz]

The documentation's use of "most cases" is suspect. For any case where you want your object to act like a primitive value when operated on, fallback => 1 should be specified.

[guest20]

autogenerate => ['ne'],

Manually specifying this:

• does not sound very "auto"
• is not very DWIM

[skington]

Well, the assumption was that if you don't want to break backwards compatibility, you need people to opt in to the new feature. In practice I'd expect that saying e.g. autogenerate => [':5.44'] (or whichever version of Perl first introduced synthesising ne) would pull in the defaults for that version.

[guest20]

Perhaps a better way to put it is that it sounds more like a bug fix.

If somebody has code that depends on the old behaviour they will want to opt out until they can track down the bugs in their code and adjust them to work with the new, bug-fixed behaviour.

The optout is overloading ne to sub { 0 }

Requesting the "new" behaviour is in everybody's code forever. Requesting the old behaviour is only in old code from the time the authors update until the time they patch the bug out of their code.

[tonycoz]

I think it's reasonable (C++ 20 does it, for example, C# requires == and != to be defined as a pair.

The only way I can see it causing backward compatibility would be if a class tested that the equal worked while not equal didn't

[ap]

I think this is something that can only be answered by attempting it. I can conceive of this causing a surprising amount of fallout due to some subtlety that isn’t easy to see without being knee-deep in the details of this area. I can just as easily conceive of it causing virtually or even entirely no issues. And no issues, it seems a no-brainer. If tons of fallout, I’d call it a no-go – it doesn’t seem important enough to pay for the friction in the ecosystem. If there is some fallout but not massive, it would be a judgement call. That might be when we think about adding API surface for example.

I don’t know anything about the guts that would have to be patched but it seems to me like this should not be too much effort to implement? If it wouldn’t be a huge waste of effort if we decided against it, I’d say just go for it and we’ll find out.