On Thu, Aug 6, 2020 at 5:24 AM Benas IML <benas.molis....@gmail.com> wrote:
> On Thu, 6 Aug 2020 at 11:45, Rowan Tommins <rowan.coll...@gmail.com> wrote: > > > On Thu, 6 Aug 2020 at 09:12, Benas IML <benas.molis....@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. 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. 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() {} 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 - It is equally or more concise than grouped attributes without adding complexity to the parser/compiler - It offers a clean, simple way to support nested attributes in the future if we so desire - It is conceptually closest to the docblock syntax the PHP community is familiar with - It is aligned with the attribute semantics of the majority of C family languages Best regards, Theodore -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
