Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111040
MIME-Version: 1.0
References: <CAF+90c9ow-_=DSZ9LFhKzA1ZgHcf0LPt-p7tnhKRcgVUBnLfZw@mail.gmail.com>
 <CAF+90c8m_4v_fdJfFMH+mHRf7qxps1zzrmCbVsAfQOjBmOhqFw@mail.gmail.com>
 <CAF+90c_hjNrsOfesH=y4_cUPj5J2KsWH0e83xnrXsaV0eX_HLw@mail.gmail.com>
 <DM6PR07MB66182B39AC3575CD7F5B8326F97F0@DM6PR07MB6618.namprd07.prod.outlook.com>
 <CAF+90c87-KG02MkbTc_2Vr4QZGYVj8dZLXEdviWHUx9d7so54w@mail.gmail.com>
In-Reply-To: <CAF+90c87-KG02MkbTc_2Vr4QZGYVj8dZLXEdviWHUx9d7so54w@mail.gmail.com>
Date: Thu, 16 Jul 2020 10:27:02 +0200
Message-ID: <CAOWwgpnEye=hUMoWmRrWGv6VEz8zj-hMKhFkW-Z5695PUrV4dQ@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: tyson andre <tysonandre775@hotmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000c4e8f105aa8ace22"
Subject: Re: [PHP-DEV] Re: [RFC] Treat namespaced names as single token, relax
 reserved keyword restrictions
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--000000000000c4e8f105aa8ace22
Content-Type: text/plain; charset="UTF-8"

> > > > 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.
> >
> > One possibility would be to split it up into two separate RFCs:
> > (This would probably be too short notice, and this isn't similar to any
> > proposal in the past)
> >
> > 1. An Yes/No RFC requiring a 2/3 majority for accepting the amended `@@`
> > attribute syntax with the restriction the original RFC proposed (no
> > whitespace&reserved words.
> >
> >    I'd think that very few proponents of `@@` had plans to mix whitespace
> > with backslashes in attributes when reading that RFC, and it's extremely
> > similar to the original attribute syntax change RFC.
> >
>
> While I don't think anyone had plans to mix whitespace, this is indicative
> of a larger issue. While I'm one of the people who voted for @@ as my first
> choice before, I wouldn't do so now (even with this RFC accepted). This
> issue made me realize that there is more at stake here than just "which
> syntax is prettier?" and choices that have a "closing tag" are technically
> more favorable, especially if we consider future extensions of the
> attribute system that may introduce additional ambiguities (e.g., Rust
> allows placing attributes pretty much everywhere in code -- how sure are we
> that there will be no unanticipated ambiguities?)
>
> Probably the most unambiguous treatment here would be to simply rerun the
> vote on the short attribute syntax after this RFC is decided one way or
> another, but that would be quite a bit of process overhead, for what is a
> small issue to most people.
>
>
> > 2. A yes/no RFC for this RFC to affect everything except the choice of
> > attribute syntax.
> >    (i.e. if 2 passes but not 1, we'd end up using `<<Attribute\Name>>` in
> > 8.0 and forbidding `<<Attribute \ Name>>`)
> >
>
> Just to be clear, the whitespace issue affects only the @@ syntax, not the
> <<>> or #[] syntaxes.
>

It is my understanding that implementation concerns are a valid reason to
invalidate a vote, especially when they are found after the vote happened.

If we really want to keep the @@ syntax, there might still be a way: the
syntax could require using brackets after the attribute name:

@@Foo => @@Foo()

But I voted for #[Foo] so I'm not preaching my own preference by making
this suggestion ;)

Nicolas

--000000000000c4e8f105aa8ace22--