wt., 9 cze 2020 o 13:56 Benjamin Eberlei <kont...@beberlei.de> napisał(a):
> On Thu, Jun 4, 2020 at 1:55 AM Theodore Brown <theodor...@outlook.com> > wrote: > > > Hi internals, > > > > I discussed the syntax for attributes further with Benjamin, Martin, > > and several other internals developers off-list, and with their > > feedback completed an RFC proposing to use the shorter `@@` syntax > > instead of `<<>>` for attributes in PHP 8. > > > > https://wiki.php.net/rfc/shorter_attribute_syntax > > > > The goal is not to bikeshed over subjective syntax preferences, > > but to address several concrete shortcomings related to verbosity, > > nested attributes, confusion with generics and other tokens, and > > dissimilarity to other common languages. > > > > Larry's suggestion about #[Attr] makes an important argument about allowing > to declare attributes in code in PHP 7 in a forward compatible way that has > not been brought up before. > > /** @ORM\Entity */ > #[ORM\Entity] > class User {} > > This code would work on PHP 7 and 8. > > The #[] syntax would have about equally low breaking potential as @@. It > would be the same syntax as Rusts, and close to C++/C# syntax. > I just noticed a power of Rusts outer attributes which this syntax count follow in a future. Following outer attributes in Rust's we could introduce in a future syntax like <?php #![StrictTypes,Module("my_module"),Opcache(save_comments: true)] The last one used with recently proposed named arguments which could open a wide range of possibilities IMO. In Rust adding exclamation mark after hash `#!` imposes to take effect on the outer scope which inside a file would be the whole file. Going that path solution like that could possibly supersede `declare` statement in a future and allow to add compile-time attributes without breaking the language. I believe this is very important because any attribute which is not declared as a core and built-in is not taking an effect. This way it'd be possible to add new ones in future PHP versions. Even more with `zend_ast_process` it'd be possible to implement core attributes which take effect on whole file in extension. I can imagine this can possibly be discussed to allow attributes for eg. from ctor to take effect on class but am not 100% sure of it is useful. Going further with my imagination if we go that path with `#[Attribute]` we may think of adding error suppression. I know many don't like error-suppression but sometimes it's helpfull. In case of core attributes I can imagine a const value can be added renamed or removed, but the attribute remains the same then adding error suppression in a future allows to avoid crashing like for eg. #@[Jit(Jit::OPTIMISE_SOMETHING)] // where the const may exists or not, but the Jit attribute does function foo () {} In those cases we don't wanna crash the program, we may want it to continue rather without proper optimisation then not at all. I just see another use of current error-suppression operator @ to play nice with attributes. That's my 50 cents. Best regards, Michał Marcin Brzuchalski
