Hi > 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
I was going to reply these same things, but you beat me to it. But just to complement, after looking at the patches it became a bit evident that most of the concerns being raised against @@ also work against the other proposals. All have a certain level of BC break due to parsing ambiguity: - @@ can break the silence operator when it's chained (useless anyway) - #[...] breaks comments - <<...>> has problems with bit shift operators >From all these tradeoffs I'd rather compromise on breaking the useless chaining of error suppression operators, FOR SURE. I have the impression most of this thread at this point is about personal taste on what was voted rather than technical. Hopefully it's a wrong impression. > > [1]: https://externals.io/message/110568#111053 > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > Ty, Márcio -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
