PPC 21 - short circuiting and lvalue

[rabbiveesh]

What should happen with this code

$undef?->[0] = die

In the undef case, should this shortcircuit the assignment RHS, or run the code and not store it?
Similar question for

($but?->{why}, $for_sure) = (9001, 9002)

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?

[rabbiveesh]

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.

[guest20]

$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 an undef on 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

[rabbiveesh]

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

1. Bail out on the whole assignment, even for the non nully lvalue target
2. Just bail out the lvalue and treat it as a black hole for assignment
3. 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