On Wed, June 10, 2020 at 3:11 AM Michał Brzuchalski
<michal.brzuchal...@gmail.com> wrote:
> 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.
Hi Michał,
I'm really not certain it's a good thing to have another way of adding
declares which would be ignored in older PHP versions. For instance,
in your example if the code is designed to work with stricter types,
what happens if it's unexpectedly run on an older version of PHP?
Instead of erroring as it should, the code might keep running but
produce unexpected results for certain inputs.
> 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.
Please, let's not add a new place where error suppression can be used.
Yes, it's necessary when wrapping some old APIs that otherwise output
warnings, but for new APIs I really don't think this is a good idea.
Best regards,
Theodore
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
