Repository navigation
PPC 21 - short circuiting and lvalue #71
Description
Activity
For reference, this is a syntax error in JavaScript. There's a proposal here https://github.com/tc39/proposal-optional-chaining-assignment and there's some discussion about how it should work and possible edge cases.
On the other hand, swift does support this, and it shortcircuits the RHS, tho it doesn't support list assignment from what I understand.
$undef?->[0] = die
Owing to the lack of a condition, this looks like an unconditional die to me.
I'd expect an autoviv, but the
?->tells me to stop expecting those.($but?->{why}, $for_sure) = (9001, 9002)
I read
?->as a ternary with the hash element on one side, and anundefon the other, so this to turn into either:(undef, $for_sure) = (9001,9002) # discarding the first thing
- or -($but->{why}, $for_sure) = (9001,9002) # The first thing goes into the hash
I think I'd be upset if either of these short circuited
In my branch for optchain, I have an implementation where I use a dummy node so the bailout CAN work, tho the multiassign case still needs work as to what it would even imply
Roughly 3 options
- Bail out on the whole assignment, even for the non nully lvalue target
- Just bail out the lvalue and treat it as a black hole for assignment
- Syntax error
For the first cut, I think it makes sense to punt on lvalue entirely (precedent in JS and php), and maybe come back to it once we have an idea what the scope should be
What should happen with this code
In the undef case, should this shortcircuit the assignment RHS, or run the code and not store it?
Similar question for
Considering the second, it would seem like we wouldn't necessarily wanna short circuit. Perhaps it doesn't make sense to use optchain as an lvalue?