PPCs icon indicating copy to clipboard operation
PPCs copied to clipboard

[PPC0021] - more clarification for the short circuit behavior

Open rabbiveesh opened this issue 1 year ago • 5 comments

Given the following code

@{ $possibly_undef?->[0] }[0..10]

What should happen if $possibly_undef is undef? had it been a chain, then it's obvious that the final slice operation would be skipped. Do we want this behavior also in the event that an equivalent expression has been made that just so happens to not be in a "chain"?

I vote yes, b/c the logic for skipping deeper parts of the chain (ostensibly) is "given that i'm trying to fetch some value deep inside this thingy, all fetching of values will be obviously undef, so let's just return undef now". That would apply to this use case also.

I'll happily submit a PR including this as a more peculiar case once i get the feeling that this I am correct that this behavior is correct

rabbiveesh avatar Nov 30 '24 18:11 rabbiveesh

Autoviv $possibly_undef to an empty array-ref.

guest20 avatar Nov 30 '24 21:11 guest20

Autoviv $possibly_undef to an empty array-ref.

I don't understand your suggestion. That's not even on the table, seeing as optional chaining skips autovivifying. Are you being sarcastic?

rabbiveesh avatar Dec 01 '24 11:12 rabbiveesh

Given the following code

@{ $possibly_undef?->[0] }[0..10]

In my understanding, cirmcumfix dereference and post-dereference do exactly the same thing, so I would read the above code as:

$possibly_undef?->[0]->@[0..10];

What should happen if $possibly_undef is undef? had it been a chain, then it's obvious that the final slice operation would be skipped. Do we want this behavior also in the event that an equivalent expression has been made that just so happens to not be in a "chain"?

I think so.

I vote yes, b/c the logic for skipping deeper parts of the chain (ostensibly) is "given that i'm trying to fetch some value deep inside this thingy, all fetching of values will be obviously undef, so let's just return undef now". That would apply to this use case also.

So if that expression was on the right side of an assignment (I'm replacing 10 by 2, for readability), you'd get:

# scalar: 3 times undef
my ( $v0, $v1, $v2 ) = @{ $possibly_undef?->[0] }[0..2];

# list: empty list
my @v = @{ $possibly_undef?->[0] }[0..2];

I'll happily submit a PR including this as a more peculiar case once i get the feeling that this I am correct that this behavior is correct

Yes, the more examples and corner cases, the better. All should end up in the test suite.

book avatar Dec 01 '24 13:12 book

So if that expression was on the right side of an assignment (I'm replacing 10 by 2, for readability), you'd get:

# scalar: 3 times undef
my ( $v0, $v1, $v2 ) = @{ $possibly_undef?->[0] }[0..2];

Sorry, this is still a list context (not scalar), but assigning from the empty list into scalar variables would leave each of them undef anyway.

A third example could be:

# $v is undef, @v is empty
my ( $v, @v ) = @{ $possibly_undef?->[0] }[0..2];

book avatar Dec 01 '24 13:12 book

@rabbiveesh I would expect a syntax like that to autoviv since that's how arrows and square brackets work in perl, so I suggested it should autoviv.

I was on my phone on a tram, and there wasn't an easy way to navigate from the issue to the actual PPC document so I didn't do the reading before commenting.

guest20 avatar Dec 01 '24 13:12 guest20