Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111151
MIME-Version: 1.0
References: <alpine.DEB.2.23.453.2007221247530.7489@singlemalt.home.derickrethans.nl>
 <CAESVnVqprgkgcjYPs5pE6pMe2b=LoZxfKDB1F-8NDwoo_ab83w@mail.gmail.com>
 <CAESVnVqaMs73HS583BoT2o4TEV8weFUTDKnwdUNq1YgfrYLVgA@mail.gmail.com>
 <1ed9899c-3816-4646-bad7-4110e4a68978@DM3NAM05FT049.eop-nam05.prod.protection.outlook.com>
 <BYAPR05MB6535142CA234E79725D2254CDE760@BYAPR05MB6535.namprd05.prod.outlook.com>
In-Reply-To: <BYAPR05MB6535142CA234E79725D2254CDE760@BYAPR05MB6535.namprd05.prod.outlook.com>
Date: Thu, 23 Jul 2020 12:04:29 -0300
Message-ID: <CAOsHV+tn=GR9g9toz5zgV=_OQrHkd5tUibJDvxZ45KvObgFy+w@mail.gmail.com>
To: Theodore Brown <theodorejb@outlook.com>
Cc: Mark Randall <marandall@php.net>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?
From: 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 fro=
m the
> > > last vote would obviously take precedence.
> >
> > I don't believe the concern is that we have something unworkable sittin=
g
> > 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 th=
e
> > 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=C3=A1rcio