New to the discussion and being this deep; so, apologies for any bumps. Mainly questions.
Does this only affect the string after the “namespace” keyword (make implicit explicit)? So, things like “use” with a stack of classes within a base namespace would still be possible? On reserved words, if I had class “String” would that still throw a reserved word violation? Cheers, Josh > On Jul 14, 2020, at 5:52 AM, Brent Roose <bre...@stitcher.io> wrote: > > Hi Nikita > > What happens to the attributes syntax if this RFC doesn't pass? > > Furthermore, I think voting against this RFC to prevent the @@ syntax from > happening is an abuse of the system. If there are problems with the attribute > syntax, than the vote results on that one should be called void and a revote > should happen, but it shouldn't affect the vote of this RFC, which has a > larger impact than just the attributes syntax. > > Kind regards > Brent > > > >> On 14 Jul 2020, at 11:09, Nikita Popov <nikita....@gmail.com> wrote: >> >>> On Thu, Jul 9, 2020 at 4:33 PM Nikita Popov <nikita....@gmail.com >>> <mailto:nikita....@gmail.com>> wrote: >>> >>> On Tue, Jun 16, 2020 at 10:52 AM Nikita Popov <nikita....@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 > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
