develooper Front page | perl.perl5.porters | Postings from June 2021

Re: PSC #024 2021-06-11

Thread Previous | Thread Next
Tony Cook
June 14, 2021 01:43
Re: PSC #024 2021-06-11
Message ID:
On Sun, Jun 13, 2021 at 10:01:33AM +0100, Neil Bowers wrote:
> Assignment to undef, and a quirk

> Tony C submitted a PR on 2021-06-02 which changes the behaviour on
  assigning to undef within a ternary[4]. We discussed whether
  assigning should be legal in any context. But we then ended up
  looking at what was really going on with ($x ? $y : undef). Rik
  started dumping out op trees for different examples, and bouncing
  back & forth with Nick on what was going on. Oh how naive I was,
  thinking the previous topic went on for a long time. Rik is going to
  email a summary of this, with a suggestion for what might change.

It's a bit strange.

The () around the ternary sets OPf_PARENS on that op tree, but at that
point the op modified is a null op, with cond_expr as the child, and
the flag is set on that null op.

When newASSIGNOP() checks for list assignment it sees the null op,
skips it and starts checking from the child op, but this ends up not
being an issue, since...

Ternary ops have their own check before the parens check that
recursively performs the same checks on the true and false
expressions, so code like:

  $x ? ($y) : (undef) = ...;

actually becomes the list assignment we might have expected from:

  ($x ? $y : undef) = ...;

It would be close to trivial to modify the behaviour to look for
parens in addition to the checks of the child ops, but that would
change the context of the right side of the assignment:

  ($x ? $y : undef) = foo(); # foo() currently called in scalar context

which would be a silent change in behaviour.

We could hide it behind a feature flag, but it's subtle enough I could
see it causing problems if that flag was later included in a feature


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About