PHP Internals News: Episode 94: Unwrap Reference After Foreach

Thursday, August 26th 2021, 09:22 BST

In this episode of "PHP Internals News" I chat with Nikita Popov (Twitter, GitHub, Website) about the "First Class Callable Syntax" RFC.

The RSS feed for this podcast is https://derickrethans.nl/feed-phpinternalsnews.xml, you can download this episode's MP3 file, and it's available on Spotify and iTunes. There is a dedicated website: https://phpinternals.news

Transcript

Derick Rethans 0:14: Hi, I'm Derick. Welcome to PHP internals news, the podcast dedicated to explaining the latest developments in the PHP language. This is Episode 94. Today I'm talking with Nikita Popov about the unwrap reference after foreach RFC that he's proposing. Nikita, would you please introduce yourself?
Nikita Popov 0:33: Hi, Derick. I'm Nikita and I work at JetBrains on PHP core development.
Derick Rethans 0:38: So no changes compared to the last time.
Nikita Popov 0:41: Yes, at the time before that.
Derick Rethans 0:43: So what is the problem that is RFC is going to solve?
Nikita Popov 0:46: Well, it's really a very minor thing. I think it's a relatively well known problem for the more experienced PHP programmers. It's like a classic example, you have a foreach loop by reference. So foreach array as value by reference, and then you do a second loop after that, foreach array as value at the same it's by value. So without the reference sign. The result of that is that your last two array elements are going to be the same, which is kind of unexpected. If you're not familiar with how references in PHP work and scoping in PHP works. So I think it's worth explaining what's going on there.
Derick Rethans 1:27: Can you quickly explain the scoping or rather the lack of it, I suppose?
Nikita Popov 1:31: Yeah, it's really the lack of PHP really only has function scoping. So if you have a foreach array as value, then the value variable is going to stay alive, even after the foreach loop. And usually, that won't make much of a difference. So you will just have like reference to the last element of the array, might even be useful for some cases, you know, before we added the array, I think, array_key_last function. If the last element now is a reference, so if you have a reference to the last element, then you're write into that variable is also going to modify the last element of the array. So if you now have a second foreach loop, using the same variable, that's actually not just modifying that variable, but it's also always modifying the last element of the array.
Derick Rethans 2:15: Okay, just to clarify, it isn't necessarily the last element in the foreach loop. It's the last one that's been assigned to?
Nikita Popov 2:22: Yeah, that's, that's true.
Derick Rethans 2:24: Is this not something that people actually use for some useful reasons?
Nikita Popov 2:28: As mentioned before, technically, you could use it to get a reference to the last element and then modify the last element outside the foreach loop. I don't think this is a particularly common use case. But I'm sure people have used in here there. This is a use case we would break with the proposed RFC.
Derick Rethans 2:47: I think it is one I have used in the past, it's probably not how I would do it now. But I'm pretty sure I have some point in the past. What are you proposing to change with this RFC?
Nikita Popov 2:57: The change is pretty simple. And that's to unwrap or to break the reference after the loop. You will still have like after the loop, the variable will still contain the value of the last element, or of the last like visited element, but it will no longer be a reference to it. If you write into the variable, it will not modify the original array. And if you have a second loop that writes into the variable that also doesn't modify the original error any more.
Derick Rethans 3:25: At which point and how is this reference broken?
Nikita Popov 3:29: It's at the end of the foreach loop, or as you say, if you break out too early, then of course, it would also get broken. So it's referenced inside the foreach loop and stops being referenced outside the loop.
Derick Rethans 3:41: And that would happen also, if I would use a goto for example?
Nikita Popov 3:45: Oh, that that's a trick question, actually, yes, it should happen. But now that you have mentioned it, I think my current implementation does not handle that particular case, I will have to double check it. But that should happen, yes.
Derick Rethans 4:00: It's good to know that you've thought about it then.
Nikita Popov 4:02: Well, I didn't think about it. Because I mean, I guess I can mention it here, the way this works is that well, at the end of the foreach loop, we have like an instruction that frees the loop variable. And I can just add an additional one that breaks reference. But if you use things like goto or multi level breaks, or something like that, then we insert these clean-up instructions before the jump. We have to make sure to actually insert the reference breaking instruction there as well. So it's like not automatically handled.
Derick Rethans 4:38: Is this going to be a separate instruction or as we tend to call them opcodes?
Nikita Popov 4:43: I'm using a separate one, but one could run it as a flag into the instruction that frees the loop variable, but I think it's cleaner to have a separate instruction for it. Like technically one could optimize it away in some cases, like I wouldn't bother but it's like semantically a different thing.
Derick Rethans 5:01: I think it'd be nicer result, because it makes it easier to visualize what's happening, right?
Nikita Popov 5:06: Yeah, it is.
Derick Rethans 5:07: Did you actually check whether some code uses this construct?
Nikita Popov 5:10: I have to admit, I tried checking it using a very basic approach, just look at foreach loops by reference. And then if the variable is used after that. But that kind of primitive approach has way too many false positives, for example, you have a foreach loop inside, and if, and then the variable is reused inside an else. So it like wouldn't flow from the if into the else. So you would have to do some kind of more sophisticated control flow analysis. It's something that can be done, but I didn't bother doing it for a one off backwards compatibility check. So I don't have any hard data on how much code is actually using something like this.
Derick Rethans 5:51: So this is where I'm a little bit on the fence about this change, because it is changing behaviour, that's going to be pretty hard to figure out what is actually going to affect your codebase.
Nikita Popov 6:01: ...