On Thu, Jul 16, 2020 at 3:40 AM tyson andre <tysonandre...@hotmail.com> wrote:
> > > 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. Nikita Still, my proposal seems like a dissatisfying one. > > Allowing future 3+-way votes to be re-voted once due to unexpected > implementation concerns > (when the original authors are among the authors of the amendment) > with a 50% majority requirement (instead of 2/3) might help in the future, > but would probably entail its own process vote for an extremely > rare/narrow RFC situation. > That wouldn't help with this RFC due to the feature freeze, > and I think that situation's too rare to actually work out details and > actually propose that amendment. > > P.S. I'm in favor of removing whitespace between tokens of names. > > - Tyson
