rfc:namespaced_names_as_token
Differences
This shows you the differences between two versions of the page.
Next revision | Previous revisionNext revisionBoth sides next revision | ||
rfc:namespaced_names_as_token [2020/06/15 15:16] – created nikic | rfc:namespaced_names_as_token [2020/07/09 14:01] – nikic | ||
---|---|---|---|
Line 2: | Line 2: | ||
* Date: 2020-06-15 | * Date: 2020-06-15 | ||
* Author: Nikita Popov < | * Author: Nikita Popov < | ||
- | * Status: | + | * Status: |
* Target Version: PHP 8.0 | * Target Version: PHP 8.0 | ||
- | * Implementation: | + | * Implementation: |
===== Introduction ===== | ===== Introduction ===== | ||
- | PHP currently treats namespaced names like '' | + | PHP currently treats namespaced names like '' |
- | The motivation | + | There are two motivations: |
<PHP> | <PHP> | ||
Line 26: | Line 26: | ||
As you can see, both references of '' | As you can see, both references of '' | ||
- | To provide another example, what would happen if '' | + | Additionally, treating namespaced names as a single token avoids certain syntactical ambiguities. For example, the [[rfc: |
<PHP> | <PHP> | ||
- | // This line would remain legal | + | function test(@@A |
- | use MyCLabs\Enum\Enum; | + | // Can be interpreted as: |
- | + | function test( | |
- | // This line would still result in a parse error | + | @@A\B |
- | class Action extends Enum { } | + | $param |
- | </PHP> | + | ) {} |
- | + | // Or: | |
- | This means that code using the enum library will very likely break, but there are easy ways to avoid it, possibly by automated means: | + | function test( |
- | + | @@A | |
- | < | + | \B $param |
- | class Action extends \MyCLabs\Enum\Enum | + | ) {} |
- | // or | + | |
- | use MyCLabs\Enum\Enum as Enum_; | + | |
- | class Action extends Enum_ { } | + | |
</ | </ | ||
- | This makes it possible | + | This RFC resolves this by making the first variant a syntax error, and requiring you to write whichever interpretation was intended. This proposal |
===== Proposal ===== | ===== Proposal ===== | ||
Line 72: | Line 69: | ||
// Before: T_NS_SEPARATOR T_STRING | // Before: T_NS_SEPARATOR T_STRING | ||
// After: | // After: | ||
- | // Rule: {LABEL}(" | + | // Rule: |
namespace\Foo; | namespace\Foo; | ||
Line 83: | Line 80: | ||
<PHP> | <PHP> | ||
- | // This is interpreted as T_LIST | + | // This is interpreted as T_LIST |
List | List | ||
// All of the following are interpreted as legal namespaced names: | // All of the following are interpreted as legal namespaced names: | ||
Line 91: | Line 88: | ||
</ | </ | ||
- | Whitespace is not permitted between namespace separators. If it occurs, the namespace separator will be parsed as '' | + | Whitespace is not permitted between namespace separators. If it occurs, the namespace separator will be parsed as '' |
<PHP> | <PHP> | ||
Line 107: | Line 104: | ||
// This would have previously been interpreted as $foo = Foo\call($bar), | // This would have previously been interpreted as $foo = Foo\call($bar), | ||
// now it will result in a parser error. | // now it will result in a parser error. | ||
- | $foo = Foo | + | $foo = Foo // <- Missing semicolon |
\call($bar); | \call($bar); | ||
</ | </ | ||
- | In additional to the namespaced | + | In this interest of consistency, |
<PHP> | <PHP> | ||
- | class KEYWORD {} | + | namespace iter\fn; // Legal |
- | interface KEYWORD {} | + | namespace fn; // Legal |
- | trait KEYWORD {} | + | |
- | function KEYWORD() {} | + | |
- | const KEYWORD = 0; | + | |
- | use Foo as KEYWORD; | + | |
</ | </ | ||
- | It should be emphasized that it will not be possible to refer to symbols that use keyword names by directly using the keyword, it always needs to be part of a namespaced name that renders its usage unambigous: | + | This is to avoid a discrepancy where defining |
<PHP> | <PHP> | ||
- | class List {} | + | namespace namespace; |
- | + | namespace namespace\x; // Illegal | |
- | new List; // Parse error. | + | |
- | new \List; // Ok! | + | |
</ | </ | ||
+ | |||
+ | This avoids introducing an ambiguity with namespace-relative names. | ||
===== Backward Incompatible Changes ===== | ===== Backward Incompatible Changes ===== | ||
Line 149: | Line 142: | ||
As such, the practical impact is very limited, and any issues are trivial to fix. On the other hand, this change will reduce the backwards-compatibility impact from any future keyword additions. | As such, the practical impact is very limited, and any issues are trivial to fix. On the other hand, this change will reduce the backwards-compatibility impact from any future keyword additions. | ||
+ | |||
+ | Additionally tooling based on '' | ||
===== Vote ===== | ===== Vote ===== | ||
Yes/No. | Yes/No. | ||
+ | |||
+ | ===== Future Scope ===== | ||
+ | |||
+ | An earlier version of this RFC also relaxed various reserved keyword restrictions for class, function and constant declarations. Because these have to deal with more perceived ambiguities, | ||
rfc/namespaced_names_as_token.txt · Last modified: 2020/07/31 12:54 by nikic