> > > > 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
