Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

  111150
July 23, 2020 14:09 theodorejb@outlook.com (Theodore Brown)
On Thu, July 23 2020 at 1:26 AM Mark Randall <marandall@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
  111151
July 23, 2020 15:04 marcio.web2@gmail.com (Marcio Almada)
Hi

> On Thu, July 23 2020 at 1:26 AM Mark Randall <marandall@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
  111154
July 23, 2020 15:31 benas.molis.iml@gmail.com (Benas IML)
Just to chime in, `<<...>>` does not have any BC implications or problems
with bit shift operators.

On Thu, Jul 23, 2020, 6:05 PM Marcio Almada web2@gmail.com> wrote:

> Hi > > > On Thu, July 23 2020 at 1:26 AM Mark Randall <marandall@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 > >
  111155
July 23, 2020 16:11 david.proweb@gmail.com (David Rodrigues)
I think that we need some symbol that isn't open-and-close like << and >>,
because it will conflict with shift operation, and basically all
open-and-close options are used for other things; or that confuses with
error suppression like @@ and comments like #[].

Maybe we really need a new keyword, so we can apply it "as a function":
attr(Attribute(), Attribute()) function () {...} or attribute().

Or even more complex syntaxes, like: [: Attribute :].


Atenciosamente,
David Rodrigues


Em qui., 23 de jul. de 2020 às 12:32, Benas IML iml@gmail..com>
escreveu:

> Just to chime in, `<<...>>` does not have any BC implications or problems > with bit shift operators. > > On Thu, Jul 23, 2020, 6:05 PM Marcio Almada web2@gmail.com> wrote: > > > Hi > > > > > On Thu, July 23 2020 at 1:26 AM Mark Randall <marandall@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 > > > > >