On Tue, Aug 11, 2020 at 7:26 AM Chris Riley <t.carn...@gmail.com> wrote:
> On Tue, 11 Aug 2020 at 13:21, Derick Rethans <der...@php.net> wrote:
>
> > On Tue, 11 Aug 2020, Chris Riley wrote:
> >
> > > Quick question.
> > >
> > > What is the expected behaviour of:
> > >
> > > @[Bar()];
> > > class Foo {}
> >
> > That will error out in PHP 8, with:
> >
> > Parse error: syntax error, unexpected token ";" in Standard input code on
> > line 2
>
> Is
>
> <?php @[Bar()]; ?>
>
> on it's own an error?
Yes. Basically this is an example of valid code in PHP 7 that will
break if @[] is adopted. However, it will remain valid to write the
following:
@ [Bar()]; // suppressed function call
@[ Bar() ] // attribute
class Foo {}
Is this still confusing? I think so. People could easily expect
that the first line is an attribute, or that attributes *should*
be followed by a semicolon since they have an ending bracket.
**This could even make it easier to sneak vulnerabilities into PHP
projects.** :\
A second downside of @[] that doesn't appear to have been discussed
yet is typability. On my keyboard, it requires four different keys
on different sides of the keyboard, whereas @@ just requires two keys.
Thirdly, the @[] syntax with grouping removes the ability to easily
grep for attributes, which was one of the benefits of @@ mentioned in
the Shorter Attribute Syntax RFC.
Unfortunately, this new RFC fails to mention any of these issues,
thus presenting an incomplete picture of the pros and cons which
appears to be influencing the vote results against @@.
@[] has had relatively little discussion compared to the other syntax
options so far, and not all of its issues may even be known yet.
Best regards,
Theodore
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
