Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110996
MIME-Version: 1.0
References: <CAF+90c9ow-_=DSZ9LFhKzA1ZgHcf0LPt-p7tnhKRcgVUBnLfZw@mail.gmail.com>
 <CAF+90c8m_4v_fdJfFMH+mHRf7qxps1zzrmCbVsAfQOjBmOhqFw@mail.gmail.com>
In-Reply-To: <CAF+90c8m_4v_fdJfFMH+mHRf7qxps1zzrmCbVsAfQOjBmOhqFw@mail.gmail.com>
Date: Tue, 14 Jul 2020 11:09:38 +0200
Message-ID: <CAF+90c_hjNrsOfesH=y4_cUPj5J2KsWH0e83xnrXsaV0eX_HLw@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000a878f205aa632b72"
Subject: Re: [RFC] Treat namespaced names as single token, relax reserved
 keyword restrictions
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000a878f205aa632b72
Content-Type: text/plain; charset="UTF-8"

On Thu, Jul 9, 2020 at 4:33 PM Nikita Popov <nikita.ppv@gmail.com> wrote:

> On Tue, Jun 16, 2020 at 10:52 AM Nikita Popov <nikita.ppv@gmail.com>
> wrote:
>
>> 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...
>

Heads up: I plan to open voting on this proposal tomorrow, unless there is
further feedback.

Nikita

--000000000000a878f205aa632b72--