On Thu, July 23 2020 at 1:26 AM Mark Randall <marand...@php.net> wrote:
> On 23/07/2020 02:00, Sara Golemon wrote: > > Regards the vote; I don't believe that @@ has been proven unworkable, > > however if I'm wrong about that, then the second choice selection from the > > last vote would obviously take precedence. > > I don't believe the concern is that we have something unworkable sitting > in front of us right now, after all if that were the case we would not > be needing to have this conversation as the RFC would already have been > rendered void. > > What we do have, is a deep sense of unease that we collectively made the > wrong decision, based on, in part, incomplete information. > > While the initial block to @@ has been remedied by a larger > language-level change, that the problem existed at all provided a clear > example of the widely unforeseen challenges associated with the @@ > syntax and its lack of closing tags, and focused renewed attention on > long-term consequences which where perhaps not given enough > consideration during the vote. > > There has been one occurrence already, there will likely be more in the > future. But what specifically will they be and how severe? We likely > will not know until they happen. Hi Mark, I don't agree that there "will likely be more in the future". When I asked Nikita if he could think of any example that would end up being a problem, the only one he listed was a infinite parser lookahead requirement if a) attributes were allowed on statements and b) generics were implemented with curly braces instead of angle brackets. He noted that "it's unlikely we'd actually do that" and ended his email by saying "it is more likely than not, that we will not encounter any issues of that nature." [1] The @ attribute syntax has been used in other C family languages for years, and to my knowledge hasn't caused any problems in practice. It is actually the <<>> variant that is more likely to back us into a corner when it comes to future syntax like nested attributes (the RFC authors considered it to cross a line of unacceptable ugliness, and the alternative `new Attribute` syntax has technical problems). This may be one reason Hack is moving away from it to @. > But what we can say with reasonable confidence is we have an option > on the table that is technically superior I don't agree that #[] is technically superior. The implementation is virtually identical. The main practical difference is that hash comments could no longer start with a [ character, which would be surprising behavior and a larger BC break (there's definitely code in the wild using this right now). If you have a concrete example of syntax that is *likely* to cause a problem with @@, please share it. From my perspective, @@ is closest to the syntax used by the majority of C family languages for attributes, and thus is *least likely* to present future challenges. Best regards, Theodore [1]: https://externals.io/message/110568#111053 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
