Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98126
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.41 as permitted sender)
To: PHP Internals <internals@lists.php.net>
References: <0c5fc86b-5050-fe73-7afa-b3e5a38ad370@gmail.com>
 <1485902801.28761.5.camel@kuechenschabe>
 <1485902993.28761.7.camel@kuechenschabe>
 <26102ac0-61f4-446e-7ac1-ccf879a58f94@gmx.de>
Cc: =?UTF-8?Q?Johannes_Schl=c3=bcter?= <johannes@schlueters.de>
Message-ID: <af43373f-9d78-c043-edee-1c082e354a96@gmail.com>
Date: Thu, 2 Feb 2017 21:47:34 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <26102ac0-61f4-446e-7ac1-ccf879a58f94@gmx.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Deprecate and Remove Bareword (Unquoted) Strings
From: rowan.collins@gmail.com (Rowan Collins)

 > On 31.01.2017 at 23:49, Johannes Schlüter wrote:
 > There is another context where unquoted strings are used:
 >
 >    $a = [ "foo" => "bar" ];
 >    echo "Let's go and have a drink in a $a[foo]!";

On 01/02/2017 23:12, Christoph M. Becker wrote:
 > This is explicitly mentioned in the RFC's "Unaffected PHP Functionality"
 > section[1].  The RFC suggest to keep this shortcut.

Indeed, thanks to whoever put that section in the RFC template. :)

I do think it is a rather odd syntax rule, and not one I would include 
if designing PHP from scratch, particularly since putting single quotes 
around the key...

echo "Let's go and have a drink in a $a['foo']!";

...results in a rather surprising error:

Parse error: syntax error, unexpected '' (T_ENCAPSED_AND_WHITESPACE), 
expecting identifier (T_STRING) or variable (T_VARIABLE) or number 
(T_NUM_STRING)

The most consistent interpretation would actually be for the [ to be 
treated as just part of the string, which would never be a useful result:

Notice: Array to string conversion
Let's go and have a drink in a Array[foo]!

It's just possible that someone would expect "$message[E_WARNING]" to 
look up the constant, but since it *never* does, this is less likely to 
cause the kind of subtle bugs I describe in the RFC. Plus this syntax is 
documented and recommended, whereas the one I propose to remove appears 
to have never been either of those things.


 > Oh and there's another case:
 >
 >    foo.php?a[foo]=bar

I hadn't thought of that one; I'll add it to the RFC as also not 
changing, for all the same reasons.

Indeed, this one has no ambiguity at all, since there is no scope where 
constants could be defined in order to populate it.


 > I'm not saying we have to change those. But I believe the symmetry there
 > is part of the historic reason.

Unless Rasmus, Zeev, or Andy venture down memory lane and tell us 
otherwise, I think that's a reasonable theory. The fallback is certainly 
usually mentioned when talking about array keys, even though it applies 
to any bare word the parser sees.

Regards,
-- 
Rowan Collins
[IMSoP]