php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #71030 PHP 7.0 list() behavior
Submitted: 2015-12-04 16:41 UTC Modified: 2015-12-06 16:21 UTC
Votes:4
Avg. Score:3.2 ± 0.4
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: filippo dot desantis at gmail dot com Assigned: nikic (profile)
Status: Assigned Package: *General Issues
PHP Version: 7.0.0 OS: OSX
Private report: No CVE-ID: None
View Add Comment Developer Edit
Have you experienced this issue?
Rate the importance of this bug to you:

 [2015-12-04 16:41 UTC] filippo dot desantis at gmail dot com 
Description:
------------
I'm using

PHP 7.0.0 (cli) (built: Dec  2 2015 13:35:31)
Zend Engine v3.0.0, Copyright (c) 1998-2015 Zend Technologies

Running the example in the RFC https://wiki.php.net/rfc/abstract_syntax_tree for the list() function 

$a = [1, 2];
list($a, $b) = $a;
 
// OLD: $a = 1, $b = 2
// NEW: $a = 1, $b = null + "Undefined index 1"


I don't get the "NEW" result but the "OLD" one.

Looking for some more information I found in the documentation (http://php.net/list) the warning "Modification of the array during list() execution (e.g. using list($a, $b) = $b) results in undefined behavior.".

I was wondering which of the two behaviour should be the good one :)






Test script:
---------------
<?php

$a = [1, 2];
list($a, $b) = $a;

var_dump($a, $b);

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2015-12-05 01:36 UTC] requinix@php.net
-Status: Open +Status: Verified
 [2015-12-05 01:36 UTC] requinix@php.net 
https://3v4l.org/vBGTH

It looks like the RHS variable does not get reevaluated. This is the behavior that would make the most sense to me, but it does contradict what the AST RFC says. I haven't found any talk about changing how list() works post-RFC.

So either
a) list() is not behaving correctly, or
b) The warning can be removed and the migration guide needs to mention the change
 [2015-12-06 15:48 UTC] bwoebi@php.net
-Status: Verified +Status: Assigned -Type: Documentation Problem +Type: Bug -Assigned To: +Assigned To: nikic
 [2015-12-06 15:48 UTC] bwoebi@php.net 
The implementation is definitely not matching the RFC here.
In current code the case of list($a, $b) = $a; is special cased (basically when the RHS variable occurs on the LHS).
In that case we do a quick (COW) copy first.

Though, try:
$a = [1, 2];
$_a = "a";
list($$_a, $b) = $a; // variable variable
# or
$c = &$a;
list($c, $b) = $a; // with reference

then you'll get what's expected as per the RFC.

I wonder though whether we really should have a special case here … either for all or for none?

Assigning to Nikita (RFC author) so that he can clarify...
 [2015-12-06 16:21 UTC] nikic@php.net 
Yes, the text in the RFC is no longer correct (many parts of that RFC are outdated). We've special case list($a, $b) = $a to provide the behavior that you would intuitively expect and that complies with our normal list() evaluation semantics in PHP 7.

However the documentation is still technically correct in that we don't *guarantee* this for all possible cases, as is illustrated by bwoebi's examples.

We could guarantee it by always emitting a QM_ASSIGN for a CV RHS. It should not be overly expensive (maybe even cheaper with many list assignments). But then again, I'm not sure I see the necessity for this sort of edge case. We don't provide these kind of guarantees regarding CV evaluation order in other places either.
 
PHP Copyright © 2001-2019 The PHP Group
All rights reserved. 		Last updated: Mon Apr 22 02:01:25 2019 UTC