[RFC] Deprecate and Remove Bareword (Unquoted) Strings

php.internals

Rowan Collins

9 years ago
Good evening all! Currently, if the constant FROB_ACTIVE is not defined, the code "echo FROB_ACTIVE;" results in an E_NOTICE and the string 'FROB_ACTIVE' being displayed. I would like to propose that this be changed to an E_WARNING in PHP 7.2, and to an Error in PHP 8.0. My reasoning for this includes: - consistency with other "undefined" errors, including the otherwise identical "echo \FROB_ACTIVE;" - the fallback to string appears to be largely undocumented except to discourage its use - the error can mask serious bugs, such as when mis-typing keywords I have tried to anticipate some of the questions that will be raised, so have drafted an RFC rather than trying to fit all the detail into one e-mail: https://wiki.php.net/rfc/deprecate-bareword-strings Please read my proposal, and let me know your thoughts. I have placed the RFC "under discussion", but will be happy to modify it based on feedback, and am in no haste to put it to a vote. Regards,
-- Rowan Collins [IMSoP]

Niklas Keller

9 years ago
2017-01-29 20:33 GMT+01:00 Rowan Collins <rowan.collins@gmail.com>:
> Good evening all! > > Currently, if the constant FROB_ACTIVE is not defined, the code "echo > FROB_ACTIVE;" results in an E_NOTICE and the string 'FROB_ACTIVE' being > displayed. I would like to propose that this be changed to an E_WARNING in > PHP 7.2, and to an Error in PHP 8.0. > > My reasoning for this includes: > > - consistency with other "undefined" errors, including the otherwise > identical "echo \FROB_ACTIVE;" > - the fallback to string appears to be largely undocumented except to > discourage its use > - the error can mask serious bugs, such as when mis-typing keywords > > I have tried to anticipate some of the questions that will be raised, so > have drafted an RFC rather than trying to fit all the detail into one > e-mail: https://wiki.php.net/rfc/deprecate-bareword-strings > > Please read my proposal, and let me know your thoughts. I have placed the > RFC "under discussion", but will be happy to modify it based on feedback, > and am in no haste to put it to a vote. > > Regards, > > -- > Rowan Collins > [IMSoP] > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
I think it should emit an E_DEPRECATED instead of E_WARNING, but otherwise +1.

Nikita Popov

9 years ago
On Sun, Jan 29, 2017 at 8:33 PM, Rowan Collins <rowan.collins@gmail.com> wrote:
> Good evening all! > > Currently, if the constant FROB_ACTIVE is not defined, the code "echo > FROB_ACTIVE;" results in an E_NOTICE and the string 'FROB_ACTIVE' being > displayed. I would like to propose that this be changed to an E_WARNING in > PHP 7.2, and to an Error in PHP 8.0. > > My reasoning for this includes: > > - consistency with other "undefined" errors, including the otherwise > identical "echo \FROB_ACTIVE;" > - the fallback to string appears to be largely undocumented except to > discourage its use > - the error can mask serious bugs, such as when mis-typing keywords > > I have tried to anticipate some of the questions that will be raised, so > have drafted an RFC rather than trying to fit all the detail into one > e-mail: https://wiki.php.net/rfc/deprecate-bareword-strings > > Please read my proposal, and let me know your thoughts. I have placed the > RFC "under discussion", but will be happy to modify it based on feedback, > and am in no haste to put it to a vote. >
Fully agree with this proposal. Also agree with the choice of throwing a Warning instead of a Deprecation. Throwing a Deprecation would essentially *downgrade* the current error level, which does not appear to be prudent. Nikita

Levi Morrison

9 years ago
On Sun, Jan 29, 2017 at 1:50 PM, Nikita Popov <nikita.ppv@gmail.com> wrote:
> On Sun, Jan 29, 2017 at 8:33 PM, Rowan Collins <rowan.collins@gmail.com> > wrote: > >> Good evening all! >> >> Currently, if the constant FROB_ACTIVE is not defined, the code "echo >> FROB_ACTIVE;" results in an E_NOTICE and the string 'FROB_ACTIVE' being >> displayed. I would like to propose that this be changed to an E_WARNING in >> PHP 7.2, and to an Error in PHP 8.0. >> >> My reasoning for this includes: >> >> - consistency with other "undefined" errors, including the otherwise >> identical "echo \FROB_ACTIVE;" >> - the fallback to string appears to be largely undocumented except to >> discourage its use >> - the error can mask serious bugs, such as when mis-typing keywords >> >> I have tried to anticipate some of the questions that will be raised, so >> have drafted an RFC rather than trying to fit all the detail into one >> e-mail: https://wiki.php.net/rfc/deprecate-bareword-strings >> >> Please read my proposal, and let me know your thoughts. I have placed the >> RFC "under discussion", but will be happy to modify it based on feedback, >> and am in no haste to put it to a vote. >> > > Fully agree with this proposal. > > Also agree with the choice of throwing a Warning instead of a Deprecation. > Throwing a Deprecation would essentially *downgrade* the current error > level, which does not appear to be prudent. > > Nikita
I also agree with the choice of throwing a Warning instead of a Deprecation. I'll be happy to see this feature removed. Good riddance!

Christoph Becker

9 years ago
On 29.01.2017 at 20:33, Rowan Collins wrote:
> Currently, if the constant FROB_ACTIVE is not defined, the code "echo > FROB_ACTIVE;" results in an E_NOTICE and the string 'FROB_ACTIVE' being > displayed. I would like to propose that this be changed to an E_WARNING > in PHP 7.2, and to an Error in PHP 8.0. > > My reasoning for this includes: > > - consistency with other "undefined" errors, including the otherwise > identical "echo \FROB_ACTIVE;" > - the fallback to string appears to be largely undocumented except to > discourage its use > - the error can mask serious bugs, such as when mis-typing keywords > > I have tried to anticipate some of the questions that will be raised, so > have drafted an RFC rather than trying to fit all the detail into one > e-mail: https://wiki.php.net/rfc/deprecate-bareword-strings > > Please read my proposal, and let me know your thoughts. I have placed > the RFC "under discussion", but will be happy to modify it based on > feedback, and am in no haste to put it to a vote.
Thanks for bringing this forward, Rowan! I'm +1 on the proposal by all accounts.
-- Christoph M. Becker

Net Mo

9 years ago
Great! We can get rid of one of the most ridiculed "features" of the language :D http://php.net/manual/en/language.types.array.php#language.types.array.donts "This is wrong, but it works."

Fleshgrinder

9 years ago
Simply +1 this is a ridiculous _feature_ which never made sense in the first place. Also +1 for E_WARNING and removal of complete support in PHP 8.0.
-- Richard "Fleshgrinder" Fussenegger

Paul M Jones

9 years ago
> have drafted an RFC rather than trying to fit all the detail into one e-mail: https://wiki.php.net/rfc/deprecate-bareword-strings > > Please read my proposal, and let me know your thoughts. I have placed the RFC "under discussion", but will be happy to modify it based on feedback, and am in no haste to put it to a vote.
Happy to see this behavior removed, and appreciate the incremental approach. E_WARNING seems appropriate. Thanks for proposing it!
-- Paul M. Jones pmjones88@gmail.com http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php

Johannes Schlueter

9 years ago
Hi, On Sun, 2017-01-29 at 19:33 +0000, Rowan Collins wrote:
> Currently, if the constant FROB_ACTIVE is not defined, the code "echo > FROB_ACTIVE;" results in an E_NOTICE and the string 'FROB_ACTIVE' > being displayed. I would like to propose that this be changed to an > E_WARNING in PHP 7.2, and to an Error in PHP 8.0.
related: There is another context where unquoted strings are used: $a = [ "foo" => "bar" ]; echo "Let's go and have a drink in a $a[foo]!"; Any thoughts about continuing to allow that? johannes

Johannes Schlueter

9 years ago
On Tue, 2017-01-31 at 23:46 +0100, Johannes Schlüter wrote:
> Hi, > > On Sun, 2017-01-29 at 19:33 +0000, Rowan Collins wrote: > > Currently, if the constant FROB_ACTIVE is not defined, the code "echo > > FROB_ACTIVE;" results in an E_NOTICE and the string 'FROB_ACTIVE' > > being displayed. I would like to propose that this be changed to an > > E_WARNING in PHP 7.2, and to an Error in PHP 8.0. > > related: There is another context where unquoted strings are used: > > $a = [ "foo" => "bar" ]; > echo "Let's go and have a drink in a $a[foo]!";
Oh and there's another case: foo.php?a[foo]=bar
> Any thoughts about continuing to allow that?
I'm not saying we have to change those. But I believe the symmetry there is part of the historic reason. johannes

Christoph Becker

9 years ago
On 31.01.2017 at 23:49, Johannes Schlüter wrote:
> On Tue, 2017-01-31 at 23:46 +0100, Johannes Schlüter wrote: > >> On Sun, 2017-01-29 at 19:33 +0000, Rowan Collins wrote: >>> Currently, if the constant FROB_ACTIVE is not defined, the code "echo >>> FROB_ACTIVE;" results in an E_NOTICE and the string 'FROB_ACTIVE' >>> being displayed. I would like to propose that this be changed to an >>> E_WARNING in PHP 7.2, and to an Error in PHP 8.0. >> >> related: There is another context where unquoted strings are used: >> >> $a = [ "foo" => "bar" ]; >> echo "Let's go and have a drink in a $a[foo]!";
This is explicitly mentioned in the RFC's "Unaffected PHP Functionality" section[1]. The RFC suggest to keep this shortcut.
> Oh and there's another case: > > foo.php?a[foo]=bar > >> Any thoughts about continuing to allow that? > > I'm not saying we have to change those. But I believe the symmetry there > is part of the historic reason.
Okay, but in neither case you've mentioned there are any potential pitfalls, i.e. `foo` can't be mistaken for a constant there, because the engine expects an unquoted string. [1] <https://wiki.php.net/rfc/deprecate-bareword-strings#unaffected_php_functionality>
-- Christoph M. Becker

Rowan Collins

9 years ago
> 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]

Rowan Collins

9 years ago
On 29/01/2017 19:33, Rowan Collins wrote:
> Currently, if the constant FROB_ACTIVE is not defined, the code "echo > FROB_ACTIVE;" results in an E_NOTICE and the string 'FROB_ACTIVE' > being displayed. I would like to propose that this be changed to an > E_WARNING in PHP 7.2, and to an Error in PHP 8.0. > [...] > https://wiki.php.net/rfc/deprecate-bareword-strings
Hi, I have made some minor updates to the above RFC, and would like to open it for voting in the next few days. Changes since I first posted the RFC are: - Expanded the rationale for using E_WARNING rather than E_DEPRECATED. I always anticipated this would be the most contentious part of the proposal, but am convinced the peculiarities of the situation make this the best choice. Please read that section carefully if you are concerned, and let me know if anything remains unclear. - Settled on a proposed wording for the new Warning. I spent some time considering the best phrasing and punctuation, but if anyone would like to suggest an improvement, I am open to feedback. - Clarified the history of the feature, having successfully built PHP 2 from the archived source, and confirmed that bare words were a syntax error. As such, no non-beta version of PHP allowed unquoted strings without issuing a Notice. - Added links to Pull Requests for both php-src and php-langspec to implement the proposed wording. Amusingly, I had to change a test in php-src which seems to have been *accidentally* using an unquoted string; apparently, the configuration of that test is such that the E_NOTICE was suppressed. Please let me know if there is any feedback I should take into consideration before opening this to a vote. Regards,
-- Rowan Collins [IMSoP]