Front page | perl.perl5.porters |
Postings from April 2020
Re: chained comparisons
Thread Previous
|
Thread Next
From:
Zefram via perl5-porters
Date:
April 8, 2020 05:33
Subject:
Re: chained comparisons
Message ID:
20200408053308.ruz33yhncs4g2f77@fysh.org
Tony Cook wrote:
>+ if (UNLIKELY(SvGMAGICAL(right))) {
>+ right = sv_mortalcopy(right);
...
>prevents the duplicate get magic, though it has the cost of
>duplicating the value if it is magic,
It causes the semantic problem that the scalar passed to the comparison op
(including to any overloaded comparison sub) is not the scalar specified
by the operand expression. Most comparison code doesn't care, of course,
but in general it's allowed to care. Also note that the preexisting
semantics don't have any principle of avoiding repeated get magic,
even when comparison code isn't doing anything weird:
$ cat t0
use feature "say";
package Aaa {
sub TIESCALAR { bless([]) }
sub FETCH { say "fetching"; 3 }
}
package Bbb {
use overload
"<=>" => sub { say "overloading"; (5 <=> $_[1]) * ($_[2] ? -1 : 1) },
fallback => 1;
}
tie($a, "Aaa");
$b = bless([], "Bbb");
say "start";
say $a < $b ? "yes" : "no";
$ perl5.28.0 t0
start
fetching
overloading
fetching
yes
So it is already the case that the only viable mental model for get magic
on comparison is that processing get magic, however many times it happens,
is part of the semantics of the comparison per se. The chained comparison
system, in the form in which I implemented it, is coherent with this
model, and any change in the behaviour would require a more complex model
to explain. The patchwork semantics implied by the conditional copying
that you propose would have to be matched by a patchwork explanation,
even if we were to ignore the lvalue issue.
>Another solution might be to add op flags to each of the comparison
>ops to skip get magic on their left arguments, and set that when
>building the chain. This would be a more significant change though.
Yes, and it wouldn't play nicely with anything that customises comparison
ops. Such a less-compatible change isn't out of the question, but
seems unwarranted to me, and in any case would have to wait for the next
dev cycle.
-zefram
Thread Previous
|
Thread Next