|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #54740 Ternary operator will not work with return by reference
Submitted: 2011-05-15 22:59 UTC Modified: 2013-10-02 05:27 UTC
Avg. Score:3.8 ± 0.8
Reproduced:4 of 4 (100.0%)
Same Version:3 (75.0%)
Same OS:2 (50.0%)
From: dukeofgaming at gmail dot com Assigned:
Status: Not a bug Package: Scripting Engine problem
PHP Version: Irrelevant OS:
Private report: No CVE-ID: None
 [2011-05-15 22:59 UTC] dukeofgaming at gmail dot com
PHP fails to parse a returned by reference value when using the ternary operator. 
The test script provided illustrates a case of when it is absolutely necessary 
to return by reference; if the "&" is removed then the output would be a fatal 
error: "Fatal error: Cannot use [] for reading in <...>"

Test script:
$value	= ($condition)?(

Expected result:
No errors, should be the equivalent of having:

    $value = $some_value;
    $value = &$object->Collection[];

Actual result:
Parse error: syntax error, unexpected '&' in <...>


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2012-08-27 14:17 UTC] marrch dot caat at gmail dot com
This is a general problem with reference inside ternary operator. For ex., the following script fails with the same error:
$link = isset($i) ? (& $arr[$i]) : null;
- while the following works fine:
$link = & $arr[$i];
 [2013-10-01 14:42 UTC]
-Status: Open +Status: Not a bug -Package: Compile Failure +Package: Scripting Engine problem
 [2013-10-01 14:42 UTC]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at and the instructions on how to report
a bug at

Check the second note here:
 [2013-10-01 20:35 UTC] marrch dot caat at gmail dot com
I thoroughly read the article you mentioned, Mike, but still don't understand why the following code fails to compile:

$link = isset($i) ? (& $arr[$i]) : null;
- while the following works fine:
$link = &$arr[$i];

In this case, &$arr[$i] is a legal reference assignment, so the first code should behave equal to
if (isset($i)) {
  $link = &$arr[$i];
} else {
  $link = null;
- but this code works fine, and mentioned above isn't even compiled. What's wrong with it?
 [2013-10-02 05:27 UTC]
I meant the documentation "Note:" (warning) not the user-contributed note.
 [2013-10-02 11:12 UTC] marrch dot caat at gmail dot com
Mike, I understand that. The second note tells I caanot return a reference to an expression result, such as &$object->method() or &(new StdClass()) - I can understand that. But the code sample I provided doesn't try to do that. To make things even simplier, the following code still fails to compile:
    $link = $flag ? &$a : &$b;
It doesn't try to return a reference to an expression, just a reference to a viriable; It doesn't try doing anything that the following code doesn't:
    if ($flag)
        $link = &$a;
        $link = &$b;
And maybi I'm really stupid, but after 10 years in PHP development I still don't understand why the first code cannot be compiled :(
 [2013-10-02 11:20 UTC]
@marrch: PHP has no concept of a general & operator that takes the "reference" of a variable(whatever that's supposed to be). PHP only has a =& operator (which is really "=&" and not a combination of "=" and "&") which expects a variable on the right hand side. PHP also has a & modifier for function arguments and return values.

If you want to do yourself and others a favor, write $foo =& $bar rather than $foo = &$bar to make sure that there are no misunderstandings regarding this ;)
 [2013-10-02 11:34 UTC] marrch dot caat at gmail dot com
Thank you, Nikic! You've removed scales from my eyes. To my great pity and shame, I didn't understand that through all my working experience and really though & is a "take reference" operator, as one as exists in C/C++ etc :( Thank you once again for your explanation! Now I see this is not really a bug...
PHP Copyright © 2001-2019 The PHP Group
All rights reserved.
Last updated: Sun Jan 20 12:01:25 2019 UTC