Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111363
MIME-Version: 1.0
References: <alpine.DEB.2.23.453.2008041440380.7489@singlemalt.home.derickrethans.nl>
 <BYAPR05MB6535AE9831221566469C4503DE4A0@BYAPR05MB6535.namprd05.prod.outlook.com>
 <alpine.DEB.2.23.453.2008060741110.7489@singlemalt.home.derickrethans.nl>
 <20200806091749.64675445@mcmic-probook.opensides.be> <CANeKSiStbGZG+EOVDRfRuVo4MA7th16R-oP7V2xmPj3xHNxs_A@mail.gmail.com>
 <CALKiJKporEo8DitTBqom=u0onqwQU+MiWF45R61cGHXzU783Fw@mail.gmail.com>
 <CANeKSiRivtUWsH8ySYVtjmz3JX8mrs-OJLEin_2V+A7xt18X+A@mail.gmail.com> <BYAPR05MB65357345667E6A35EDD89025DE480@BYAPR05MB6535.namprd05.prod.outlook.com>
In-Reply-To: <BYAPR05MB65357345667E6A35EDD89025DE480@BYAPR05MB6535.namprd05.prod.outlook.com>
Date: Thu, 6 Aug 2020 20:30:12 +0300
Message-ID: <CANeKSiSFJPmrtLcuxtPh7Sov21JNJTe3SMrS4WzJa_ZCVkcViw@mail.gmail.com>
To: Theodore Brown <theodorejb@outlook.com>
Cc: Rowan Tommins <rowan.collins@gmail.com>, PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000000ed1df05ac38d8fb"
Subject: Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
From: benas.molis.iml@gmail.com (Benas IML)

--0000000000000ed1df05ac38d8fb
Content-Type: text/plain; charset="UTF-8"

Hey Theodore,

On Thu, Aug 6, 2020, 8:05 PM Theodore Brown <theodorejb@outlook.com> wrote:

> On Thu, Aug 6, 2020 at 5:24 AM Benas IML <benas.molis.iml@gmail.com>
> wrote:
>
> > On Thu, 6 Aug 2020 at 11:45, Rowan Tommins <rowan.collins@gmail.com>
> wrote:
> >
> > > On Thu, 6 Aug 2020 at 09:12, Benas IML <benas.molis.iml@gmail.com>
> wrote:
> > >
> > > > But by sacrificing a few very old codebases (that still use `#` not
> `//`)
> > >
> > > Do you have some basis for # only being used by "very old" codebases?
> As
> > > far as I'm aware, it's not deprecated, and while the PEAR style guide
> > > listed it as "discouraged", PSR-1 / 2 / 12 don't mention it at all.
> > >
> > > I agree that it is probably rarer than //... and /*...*/ but let's
> avoid
> > > unnecessary hyperbole.
>
> > A grep search was done by someone in the mailing list in the original
> > `<<...>>` to `@@...` RFC thread when discussing whether `#[` is going
> > to be a huge BC or not.
> >
> > Just about all of the matches were either from old codebases or from
> > old PHP 3-5 Metasploit exploits, which are about 5-15 years old.
>
> Hi Benas,
>
> You can look at the grep search here:
> https://grep.app/search?q=%23%5B&filter[lang][0]=PHP
>
> The first BC break in the results is from an automated pentest
> framework repository which was last updated four days ago. So it
> seems like this is still code that is being used.
>

I work myself in the cybersecurity industry and I can tell you 100% that
the automated pentesting tool you're referring to isn't using any of that
`#[` code actively. In fact, over 80% of the code/exploits stored in that
repository don't work with new software/language versions.

That's the whole point - there are hundreds of scripts in numerous
different languages designed for exploiting only specific subset of
software designed for only specific versions of PHP/other languages.

By 5-15 years, I meant the exploits themselves.

Even the current Psalm static analysis tests use # to comment out an
> array:
> https://github.com/vimeo/psalm/blob/afce2dc66ff83ccad3f3a7aa26740a5eb829b2ca/tests/LanguageServer/SymbolLookupTest.php#L453
>
> Not that these individual examples are a big problem, they simply
> illustrate that hash comments are still used in current projects,
> sometimes in ways that the #[] attribute syntax would break.
>

...and that can be fixed within 5 seconds.

`#` comments were even deprecated in PHP's ini files in 5.6.


> When it comes to the @[] alternative, it's harder to grep for actual
> usages, since this string is used in virtually every email validation
> regex. In any case, code like @[foo(), bar()] would no longer work
> without putting a space between the error suppression operator and
> array (which frankly looks pretty confusing):
>
>     $x =
>     @ [Foo()]; // an array assignment with suppressed warnings
>     @[Jit()] // an attribute
>     function bar() {}
>

Same goes without saying with `@@` where `@@` means attributes and `@ @`
means double error suppression. Albeit, that is not useful.


> If there were some important language improvement that depended on
> breaking these syntaxes, maybe it would be justified. But so far I
> haven't seen such a justification.
>
> > We are playing probabilities here but at the moment, no one has said
> > any substantial argument why `@@` is better and thus, `@[...]` seems
> > like a better option in the long term.
>
> While none of our syntax options are perfect, I believe @@ has the best
> long-term tradeoffs because:
>
> - It doesn't break useful syntax
>

Fair enough.

- It is equally or more concise than grouped attributes without adding
> complexity to the parser/compiler
>

Are we really going to debate that ~30 lines of code add complexity?

- It offers a clean, simple way to support nested attributes in the
> future if we so desire
>

I'm sorry if I'm not following the conversation but what is blocking that
in `#[]`/`@[]`.

- It is conceptually closest to the docblock syntax the PHP community
> is familiar with
>

Well, if `@@` is similar to `@` (to me it isn't), we can say that `@[]` is
also similar to `@`.

- It is aligned with the attribute semantics of the majority of C
> family languages
>

In what way `#[]` or `@[]` aren't?


> Best regards,
> Theodore


Best regards,
Benas

--0000000000000ed1df05ac38d8fb--