One of PHP’s most convenient constructs is list(). Yes, it looks like a function but it really is a construct, i.e. built into PHP. It allows for multiple variable assignment in one fell swoop. Up to quite recently, there was a discrepancy between its behavior and the manual’s documentation. While the manual said that it could not be applied to strings, the truth was that sometimes it could indeed! Here’s an example:
<?php $a="aa"; list($a,$b) = $a; var_dump($a,$b); /** RESULT: * string(1) "a" * string(1) "a" **/ ?>
A user note mentions that the string could even be the value of a simple variable to trigger this undocumented behavior. According to Dimitry Stogov, this kind of string support of list was unintentional, the result of implementing the construct rather than any conscious attempt to have string handling support. The more usual behavior is for list to behave as follows:
<?php list($a,$b) = "aa"; var_dump($a,$b); /** RESULT: * NULL * NULL **/ ?>
Looking at the outcome, you might think that the values of $a and $b are NULL, however, NULL is a data type with the unique quality of being valueless . The result means that $a and $b remain unset and thus are of type NULL. What happens to “aa” in the assignment? The answer lies somewhere in PHP’s internal source code.
The issue of the way list handles strings inconsistently cropped up on the PHP Internals List when Dmitry Stogov cited the anomaly. In fact, he authored an RFC (a formal proposal) which generously offered three possible ways of resolving the matter. The main question was whether to fix the behavior or not for the sake of consistency. Some people felt that whether list were to support strings or not, any kind of action was better than maintaining the status quo with its inconsistent results.
Fortunately, there was consensus among all who voted that a fix was in order, but then the vote split nearly 50-50 over whether to have the construct support strings. A total of 33 individuals voted with 17 in favor of disabling this aspect entirely, just one vote more than the 16 who sought string handling support for list. Just one vote made the difference. Maybe it was fair, but maybe that kind of change ought to be subject to the “2/3” voting rule.
Now that string handling support will be removed for PHP7, what should one do when that version appears in a year or so if one wishes to split a string into a list? While you are unable to do that directly, you may work around that restriction. You can manually create an array of string values and then split the array into a list as the next example illustrates:
<?php $a = array(); $a="a"; $a ="a"; list($x,$y) = $a; var_dump($x,$y); /** RESULT: * string(1) "a" * string(1) "a" **/ ?>
But, surely there must be a more automatic solution. And, there is!
<?php list($a,$b) = str_split("aa"); var_dump($a,$b); /** RESULT: * string(1) "a" * string(1) "a" **/ ?>
str_split() just as its name suggests will split the string into an array, containing two elements, each with a value of “a”. The nameless array will in turn be split into a list with each array element’s value being assigned to a corresponding list variable.
The fact that the RFC’s author and a number of other important core contributors favored list having the ability to handle strings and that proposition lost nonetheless is disappointing. Had the advocates for the proposal managed to persuade the Father of PHP, Rasumus Lerdorf, of its merit, the outcome might have been far different. Perhaps in the future the PHP Internals List will revisit this issue, especially given the very slim margin by which it lost.