[RFC] Treat namespaced names as single token, relax reserved keyword restrictions

Am 16.06.2020 um 10:52 schrieb Nikita Popov:

https://wiki.php.net/rfc/namespaced_names_as_token

+1

The RFC comes with a small backwards compatibility break related to names
that include whitespace, but will hopefully reduce the backwards
compatibility impact of future reserved keyword additions.

This statement misses the fact that code which uses token_get_all() needs
to be updated due to the new T_NAME_* tokens. The RFC itself lists this
change, so that's okay.

Hi internals,

Inspired by the recent discussion on reserved keyword reservation, I'd like
to propose the following RFC:

https://wiki.php.net/rfc/namespaced_names_as_token

This RFC makes two related changes: Treat namespaced names as a single
token, which enables use of reserved keywords inside them. And remove
reserved keyword restrictions from various declarations.

The RFC comes with a small backwards compatibility break related to names
that include whitespace, but will hopefully reduce the backwards
compatibility impact of future reserved keyword additions.

Regards,
Nikita

The only issue I have with this RFC is this:

use Foo as KEYWORD;

While this might be technically correct, it is unusable. That is:

use Foo as List;

class Bar extends List { } // this will not work

Given this, I think this specific syntax should be an error, unless I'm
missing something?

Also, does this mean we can alias to fully namespaced names now?

use \My\Foo as \Bar\Foo;
class Bat extends \Bar\Foo { } // now actually extends \My\Foo, not
\Bar\Foo (no autoload would happen?)

• Davey

Hi internals,

Inspired by the recent discussion on reserved keyword reservation, I'd like
to propose the following RFC:

https://wiki.php.net/rfc/namespaced_names_as_token

This RFC makes two related changes: Treat namespaced names as a single
token, which enables use of reserved keywords inside them. And remove
reserved keyword restrictions from various declarations.

The RFC comes with a small backwards compatibility break related to names
that include whitespace, but will hopefully reduce the backwards
compatibility impact of future reserved keyword additions.

Regards,
Nikita

Love it, thanks Nikita!

In a mail that probably went to everyone's spam folder, I asked for
opinions on allowing use of .\Foo as an alternative to Foo in the
current namespace, thus reducing friction with reserved keywords even
more. Any thoughts on that now?

Best,
Jakob

What other language allows this? None that I can think of. Do we want PHP
doing something it's most closely related languages do not allow? Why
don't they allow this? What problems are we creating by allowing this? I
can imagine this would make autoloading functions and constants by
namespace more complicated, but I'm not sure.

Hi internals,

Inspired by the recent discussion on reserved keyword reservation, I'd like
to propose the following RFC:

https://wiki.php.net/rfc/namespaced_names_as_token

This RFC makes two related changes: Treat namespaced names as a single
token, which enables use of reserved keywords inside them. And remove
reserved keyword restrictions from various declarations.

The RFC comes with a small backwards compatibility break related to names
that include whitespace, but will hopefully reduce the backwards
compatibility impact of future reserved keyword additions.

Regards,
Nikita

Hi,

The following part of the proposal is problematic: Allow keywords in definition of classes, functions, const, etc.

class KEYWORD {}
interface KEYWORD {}
trait KEYWORD {}
function KEYWORD() {}
const KEYWORD = 0;
use Foo as KEYWORD;
Under your proposal, the following code will compile without notice, but will have a different behaviour from what the programmer intended:

class Int { }

const PRINT = 2;
const YIELD = 3;

function foo(Int $b) {
    return PRINT + YIELD;
}

If it is important to allow to define classes, etc. with a keyword as name, I suggest to force the programmer to say explicitly “Yes, it is really what I want”. For example, something like the following:

class namespace\Int { }

const namespace\PRINT = 2;

Another point which is problematic, is to allow namespace as a namespace parts, since namespace\foo, although interpreted as a namespace-relative name, could be intended to be a qualified name by the programmer.

—Claude

Le 16 juin 2020 à 10:52, Nikita Popov nikita.ppv@gmail.com a écrit :

Hi internals,

Inspired by the recent discussion on reserved keyword reservation, I'd like
to propose the following RFC:

https://wiki.php.net/rfc/namespaced_names_as_token

This RFC makes two related changes: Treat namespaced names as a single
token, which enables use of reserved keywords inside them. And remove
reserved keyword restrictions from various declarations.

The RFC comes with a small backwards compatibility break related to names
that include whitespace, but will hopefully reduce the backwards
compatibility impact of future reserved keyword additions.

Regards,
Nikita

Le 16 juin 2020 à 10:52, Nikita Popov nikita.ppv@gmail.com a écrit :

Hi internals,

Inspired by the recent discussion on reserved keyword reservation, I'd like
to propose the following RFC:

https://wiki.php.net/rfc/namespaced_names_as_token

This RFC makes two related changes: Treat namespaced names as a single
token, which enables use of reserved keywords inside them. And remove
reserved keyword restrictions from various declarations.

The RFC comes with a small backwards compatibility break related to names
that include whitespace, but will hopefully reduce the backwards
compatibility impact of future reserved keyword additions.

Regards,
Nikita

In fact, for classes and namespaces, we can probably do better, namely we can lift almost all keyword restriction, not only in definition and declaration, but also in in use.

Indeed, bare names of class (and trait, interface, etc) and namespace can appear only in few, well-defined positions, where it cannot be confused with a keyword, namely:

• after a handful of keywords: new yield, class yield, instanceof yield, use yield, use foo as yield, etc.
• before a paamayim nekudotayim: yield::$foo, yield::foo(), yield::FOO;
• before a backslash: yield\foo.

As far as I can see, the only keywords that can legally appear in those positions (and therefore must remain unavailable) are: namespace (because of namespace-relative names: namespace\foo), and class (because of anonymous classes: new class { }.

(As for functions and constants, I’m still thinking that it is not a good idea to allow to define or import a symbol that cannot be used. You will make the life of few library maintainers a little easier, but you will make the life of many users a little harder.)

—Claude

Hi internals,

Inspired by the recent discussion on reserved keyword reservation, I'd
like to propose the following RFC:

https://wiki.php.net/rfc/namespaced_names_as_token

This RFC makes two related changes: Treat namespaced names as a single
token, which enables use of reserved keywords inside them. And remove
reserved keyword restrictions from various declarations.

The RFC comes with a small backwards compatibility break related to names
that include whitespace, but will hopefully reduce the backwards
compatibility impact of future reserved keyword additions.

I have reduced the scope of this RFC to handle just the issue of namespaced
names, without touching any other reserved keyword restrictions. As the
discussion shows, those are trickier, with more cases of perceived
ambiguity that may need to be mitigated.

As this proposal is now a prerequisite for
https://wiki.php.net/rfc/shorter_attribute_syntax, I have heard from a
disturbing number of people that they might vote against this proposal, not
because they disagree with it, but because that would prevent the adoption
of the @@ attribute syntax. I'm not sure what to do about that...

Regards,
Nikita