Hi Joe Ferguson, > Now that it seems the technical concerns around @@ have been resolved by > another pending, passing, RFC, I'm still here wanting us to talk about the > impact of @@ on static analysis tools. Apparently, internals doesn't care > about these projects. I care and I'm trying to help. I'm not trying to > revote until I get the vote I want. I'm just a dude that had some free time > while on vacation when he saw a chance to contribute.
3 commonly used static analyzers (for type inference) are - PHPStan and Psalm, both of which use nikic/php-parser. As Nikita Popov (the maintainer of php-parser) wrote, > Emulating #[] lexing on older versions will > definitely be a challenge for PHP-Parser. I don't think we should make > concerns of external tooling hold us back too much, but the phpcs argument > really doesn't hold water. Comparatively, it would be easy to join two adjacent `@` tokens to a single `@@` token in a single pass over token_get_all. Parsers would likely already do that or benefit from doing that for tokens such as the `match` token (T_MATCH) in php 8.0. Another commonly used static analyzer is Phan (https://github.com/phan/phan/) , which I am a maintainer of. My reasons for preferring `<<>>` or @@ over `#[` were mentioned in https://externals.io/message/111218#111239 . For phpcs and other linters, my belief is that this might be easier for simple use cases in the short term, but edge cases or ambiguities like multi-line attributes or refactorings that were safe in php 7 (such as moving `#[]` behind other tokens to another line) may cause issues for users of those tools (until those tools drop support for php 7.x and older). This is why I'd advocate for a distinct token that doesn't overlap with line comments Cheers, - Tyson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
