The @@ is terrible, are we sure we' re OK with it?

However this syntax allows it to be used on 7.4 unlike any other.   This means that the initial transition of library functionality to it will be very smooth and will not require a separate implementation of polyfills for the syntax of doctrine annotations and attributes.   With any other syntax, this would require implementing 3 separate attribute classes and a bootstrap for them:   ``` /** @Annotation */ class MyAttribute extends BaseAttribute {}   /** @Annotation */ @@\Attribute class MyAttribute extends BaseAttribute {}   abstract class BaseAttribute {}   // and bootstrap   if (version_compare(PHP_VERSION, ‘8.0’) >= 0) {     require __DIR__ . ‘/polyfill/MyAttribute.php’; } ```   For Rust-like #[xxx] nothing of this is required.   >Среда, 22 июля 2020, 20:09 +03:00 от tyson andre <tysonandre775@hotmail.com>: >  >Hi Derick, >  >> Please, let's do the sensible and use the Rusty #[...] syntax. >I'd probably re-vote for <<Attribute>> given >the fact that @@ may introduce similar parsing ambiguities in the >future >that may interfere with future language changes. (but those issues are not a certainty) > >I think that #[ has its own issues, but am open to re-voting on >it. >For example, the following snippet would get parsed differently in PHP 7.4 and PHP 8.0, given a >hypothetical JIT annotation for Opcache. >With <<Opcache\Jit>>, it would give people a clear indication that the file required >PHP 8.0, >but a one-line annotation might be silently treated differently in many subtle ways in 7.4. >It's probably possible to amend the parser make it an error to put the function declaration >on the same line or to have other # comments >within a multi-line #[ annotation, >but I really dislike the special casing it would add. > >``` >$function = array_filter( >    $values, >    #[Opcache\Jit] function(int $x) { return $x % 2 > 0; } >); >``` > >Cheers, >- Tyson >-- >PHP Internals - PHP Runtime Development Mailing List >To unsubscribe, visit: https://www.php.net/unsub.php >      -- Kirill Nesmeyanov