[RFC] Shorter Attribute Syntax Change RFC 0.2

On Tue, Aug 4, 2020 at 4:19 PM David Rodrigues david.proweb@gmail.com
wrote:

Suggestions:

$(Attribute()) (available)
$[Attribute()] (available)
<<Attribute(1 >> 2)>> (like strings escapes)

The syntax for the first two seems oddly pleasing when used within PHP.

On Tue, Aug 4, 2020 at 4:19 PM David Rodrigues david.proweb@gmail.com
wrote:

Suggestions:

$(Attribute()) (available)
$[Attribute()] (available)
<<Attribute(1 >> 2)>> (like strings escapes)

I had someone else suggest $[] to me today as well, funny coincidence :-)

Can you take the "@@ to @[] pull" request as a starting point to try if
this works with a patch?

https://github.com/php/php-src/pull/5928

This syntax is "not" familiar with docblock usage of @, as it doesn't
contain a @ :-D
It does pose difficulty for static analyers and userland parsers, because
they see the $ as a T_VARIABLE
in PHP 7.

About $() syntax:

• Number of required characters: (2+1)
• Has end delimiter: yes
• Allow grouping: yes
• Forward compatibility in PHP 7: yes
• Breaks BC of valid PHP 7 codes: no
• Used by other languages: no?
• Familiar with Docblock Usage: I don't know
• Difficulties with Userland Parsers: I don't know

And my another suggestion is use a more verbose for now, until we have a
good consensus about it "using attribute()":

• Number of required characters: (16+1)

• Has end delimiter: yes

• Allow grouping: yes

• Forward compatibility in PHP 7: yes

• Breaks BC of valid PHP 7 codes: no

• Used by other languages: no?

• Familiar with Docblock Usage: I don't know

• Difficulties with Userland Parsers: I don't know

This would definitely need a fully working patch to be a contender in the
vote.

• It's not forward compatibltle with PHP 7, because use of the syntax
  would lead to a fatal error on PHP 7 parsers or am I seeing something
  wrong?
• its not a familiar syntax for PHP developers used to @ in docblocks

Atenciosamente,
David Rodrigues

Em ter., 4 de ago. de 2020 às 11:03, Benjamin Eberlei kontakt@beberlei.de
escreveu:

Hi,

Out of Banjamin's suggestion[1], I've updated the Shorter Attribute
Syntax Change RFC to reflect that process:

https://wiki.php.net/rfc/shorter_attribute_syntax_change

Patches and comments welcome.

FWIW, this has an excemption from the RM Sara as per [2]:

• Shorter Attribute Syntax Change
  • Joe/Derick - Please make sure this RFC moves along and reaches
    conclusion by beta3, as discussed previously.

In combination to the existing proposals we already voted one, this RFC
includes a fourth option that has not been discussed before,
and could be the compromise we are all looking for :-)

@[Attr] combines both the with to use the familiar @ of many, and the wish
to have a closing symbol/termination symbol that many others have.

It does not have the downsides that Tyson found w.r.t. to #[Attr] being
interpreted as comment on PHP 7, but that also means its not forward
compatible like #[Attr] is.

It provides a small BC break where code written as @[$foo, $bar] = baz();
or $foo = @["bar" => $baz]; will not compile on PHP 8 anymore, but that
can
be easily
fixed by writing it with a space between @ and [.

cheers,
Derick

[1] https://externals.io/message/111218#111261
[2] https://externals.io/message/111286#111286

--
PHP 7.4 Release Manager
Host of PHP Internals News: https://phpinternals.news
Like Xdebug? Consider supporting me: https://xdebug.org/support
https://derickrethans.nl | https://xdebug.org | https://dram.io
twitter: @derickr and @xdebug

--

To unsubscribe, visit: https://www.php.net/unsub.php

It provides a small BC break where code written as @[$foo, $bar] =
baz(); or $foo = @["bar" => $baz]; will not compile on PHP 8
anymore, but that can be easily fixed by writing it with a space
between @ and [.

If those are the potential breaks we're choosing between, I would
favor #[...] as it provides strong forward-compatibility to drive
adoption and use at the cost of a parse error that's easily fixed
(even programmatically with a very simple script). @[...] provides no
forward compat with a roughly equal chance of easily fixed syntax
break.

Given that, the choice seems obvious to me. Change my mind?

I pretty much agree, but @[ … ] is there as a compromise as it does show
some fmailiarity with the already existing @ in doc blocks.

cheers,
Derick

--
PHP 7.4 Release Manager
Host of PHP Internals News: https://phpinternals.news
Like Xdebug? Consider supporting me: https://xdebug.org/support
https://derickrethans.nl | https://xdebug.org | https://dram.io
twitter: @derickr and @xdebug

I agree with Theodore's points, including that this is metadata on a declaration, not a declaration itself.

Is this technically true? I haven't peeked at the grammar. I suspect
it is a declaration and not an optional piece of data on a
declaration, like say public.

It looks nice for a simple attribute like @@Jit, or for a one without
arguments like the used @@Deprecated, but as soon as there are more than
one, and they each get arguments, enclosing them has its own benefits over
them just standing for themselves.

The confusing thing about this argument is that as soon as they have
arguments, attributes will have an ending delimiter whatever syntax we
choose, because nobody has ever proposed removing the parentheses around
the arguments.

Detecting the closing parenthesis requires pairing off any parentheses
inside the argument list, but that's still true of the closing bracket in
@[...]. If we make the closing delimiter some random combination like @#]]
then you still need to parse the arguments, because they could contain a
quoted string with those characters in.

While I'm generally in favour of delimited syntaxes, I'm struggling to see
the difference in value between "parentheses are mandatory even if there
are zero arguments" and "the syntax includes an extra pair of outer
brackets".

With no parameters:
@@Foo()
@(Foo)
@[Foo]
@[Foo]@

With complex parameters:
@@Foo('hello @@ world', (1+2)*3)
@(Foo('hello @@ world', (1+2)*3))
@[Foo('hello @[ world ]', [1,2,3])]
@[Foo('hello @[ world ]@ again', [1,2,3])]@

Regards,

Rowan Tommins
[IMSoP]

Out of Banjamin's suggestion[1], I've updated the Shorter Attribute
Syntax Change RFC to reflect that process:

https://wiki.php.net/rfc/shorter_attribute_syntax_change

Patches and comments welcome.

Hi Derick,

I don't agree with the main argument put forward in this RFC:

The main concern is that @@ has no ending symbol and it's
inconsistent with the language that it would be the only
declaration or statement in the whole language that has no ending
termination symbol.

Attributes are not a standalone statement or declaration; they are
metadata on a declaration. They cannot stand alone, but always
modify the following declaration, just as public and static modify
a method, or a type declaration modifies a parameter or property.

Modifying declarations (e.g. for visibility and type) do not have an
ending symbol. For example, we don't write something like:

[public] function foo([int] $bar) {}

With the @@ syntax attributes are treated consistently with type and
visibility declarations:

@@Jit
public function foo(@@Deprecated int $bar) {}

So there is nothing inconsistent about not having a termination
symbol - this is in harmony with visibility and type declarations in
PHP, as well as the attribute syntax used by a majority of C family
languages. [1]

Attributes are potentially way more complex than a visibility keyword.
As such it is a reasonable requirement to say they should have a
unified ending symbol, or more broadly speaking that attributes should
be enclosed by syntax.

Hi Benjamin,

Yes, attributes that take arguments are more complex than a
visibility keyword. Union types can also be more complex.
Nevertheless it is consistent for these declaration modifiers to
not have an ending symbol.

It looks nice for a simple attribute like @@Jit, or for a one without
arguments like the used @@Deprecated, but as soon as there are more
than one, and they each get arguments, enclosing them has its own
benefits over them just standing for themselves.

Can you clarify what benefits there are to enclosing them as soon as
there is more than one attribute with arguments? From my perspective
this just adds needless complexity without being more concise than
the @@ syntax.

To me it also looks somewhat strange and less readable to require
both a closing parenthesis and a closing bracket when an attribute
has arguments:

#[MyAttr(
    "some value",
    [1, 2, 3],
    namedArg: true,
)]

# vs.

@@MyAttr(
    "some value",
    [1, 2, 3],
    namedArg: true,
)

When it comes to supporting attribute grouping, I actually consider
this a downside of the #[], @[], and <<>> syntaxes. It complicates
the internal implementation, and makes it so developers have to
choose between two different syntaxes when adding more than one
attribute. In real-world use cases the @@ syntax is just as or even
more concise without the extra parser/compiler complexity:

#[Attr1, Attr2] # 15 chars

@@Attr1 @@Attr2 # 15 chars

# 4 lines, 53 chars not counting whitespace
@[
    AttrWithParam("foobar"),
    SomeOtherAttr("fizzbuzz"),
]

# 2 lines, 52 chars
@@AttrWithParam("foobar")
@@SomeOtherAttr("fizzbuzz")

I agree that we want the best syntax, not necessarily the best
looking syntax. I still believe that the @@ syntax offers the best
balance here. It's familiar, concise without additional complexity,
and doesn't break useful syntax the way @[] and #[] do.

Yes, we have been doing this for 20 years, adding annotations enclosed
with /** and */ with each enclosing on its own line for the most part.
We even added stars in front of every inbetween line.

we are stepping into unchartered territory here with @@ by our
standards as PHP community. Using "C familiy" as an argument that
they made @ work does not mean much, because the language itself is
just the "interface" to the implementation, each C family language
probably has vastly different parsers, concerns and approaches. It
should be right for PHP.

I agree that we should pick the syntax that is right for PHP. But how
are the #[] and @[] alternatives a better fit for the language than
@@, given that they break useful syntax, while @@ isn't useful for
anything?

It seems like on the one hand the RFC is arguing that @@ is worse
because that exact token isn't used by another language, and on the
other hand it is simultaneously being argued that we need to
implement a more verbose syntax for adding vague complexity in
the future that isn't used by any other language. Which is it?

A less vague potential extension is attribute nesting, and @@ is
arguably the best fit for this - one of the motivations for proposing
it was to allow attribute nesting while preserving readable code and
a simple internal implementation.

Best regards,
Theodore

Le Thu, 6 Aug 2020 07:48:05 +0100 (BST),
Derick Rethans derick@php.net a écrit :

From the RFC:

• No ending delimiter

As said before, it does have an ending delimiter when they are arguments since
there is the parenthesis around them. When there are no arguments I don’t see
the benefit of an ending delimiter, it’s easy to spot the end of the word.

• Doesn't allow grouping

I do not understand this argument, what is the point of grouping for @@?
Does grouping mean anything special for other syntaxes, or is it just to save
keystrokes? If it is just to get a more concise syntax when there are several
attributes, the fact that @@ do not need grouping is a pro, not a con.

• No forwards compat with PHP 7

But no BC break either, while #[] introduces BC break.

• Not used ny another language

@ is used by a lot of other languages, and @@ is the closest we can get in PHP.

Côme

On Sun, Aug 16, 2020 at 4:47 PM tyson andre tysonandre775@hotmail.com
wrote:

Hi Benjamin,

We are looking for further feedback from the community.

Thanks, the updated RFC looks much better.
Some more feedback on why the edge cases are a concern to me,
and why the lack of an ending delimiter is similar to parsing problems
already faced.

I'd agree that restarting a two-week discussion period seems excessive,
and a shorter one is fine with me.

Thank you for the feedback, the section on #[] forward compatibility is
something I want to improve a bit more today, your feedback helps a lot.

---

The references section should probably also link to the other 2 RFC
discussion threads
https://externals.io/message/111416 and the RFC discussion thread
https://externals.io/message/111218

---

Developers who are new to PHP (e.g. learning by example) or those who
spend most of their time programming in other languages such as Rust or
Java or Golang
might forget/not know that # is a supported line comment syntax, or that
attributes were introduced in 8.0 (not an earlier release).
They might see that code using these edge cases passes syntax checks in
PHP 7.4 and 8.0, and assume it'd work the same way in both versions,
leading to published code incorrectly marked as compatible with PHP 7.4.

• PHP doesn't warn about calling a user-defined function too many
  parameters, making this harder to detect.

---

The #[] syntax makes it possible and convenient to use attributes syntax,
but causes various problems for end users of code using attributes syntax.
I'd expect the drawbacks of bugs caused by edge cases such
as those in
https://wiki.php.net/rfc/shorter_attribute_syntax_change#discussion_of_forwards_compatibility_procons
to outweigh the benefits of being able to release attributes immediately.

Putting attributes on the same line as parameters or closures or anonymous
classes seems natural to do to me,
and I'd expect releases would do it eventually, whether it be immediately
in 8.0, years from now, etc.

Suppose that package A/A supports PHP 7.4|^8.0.
It depends on a package B/B 2.0 which supports PHP 7.4.
B/B depends on C/C ^4.0|^5.0, where C/C 4.x supports PHP 7
and C/C 5.0 drops support for PHP 7.
C/C 5.x uses attribute syntax on the same line as other code,
including several edge cases with one-line attributes that parse
differently in php 7.0.

    public function doDbMaintenance(
        #[MyUnused] bool $log = false,  // unused in db backend
        bool $doPotentiallyDestructiveUpdate = false,
        mixed $extraFlags = null,
    ) {...}

// B/B calls doDbMaintenance($log = true)

Then suppose that a maintainer or third-party packager (e.g. for a Linux
distro) of A/A
runs composer install with PHP 8.0 before building a package such as a
phar, rpm, or tarball
(or vendor/ checked into git) from A/A 1.0.
They would pull in B/B 2.0 and C/C 5.0, creating a release of A/A that was
buggy
but did not emit any parse, compilation, or runtime warnings if end users
ran that release with php 7.4.

Then the maintainers of A/A and C/C 5.0 would get bug reports for PHP
7.4 for mysterious behaviors with no warnings,
which would be hard to reproduce and debug, despite all involved packages
correctly specifying their dependencies.
End users would also be inconvenienced by bugs that had no obvious
indication or subtler symptoms that may take a long time to get reported.

This could be worked around by

1. Setting {"config": {"platform": {"php": "7.4.9"}}} in composer.json
   of A/A,
   or by documenting that composer install should always be run with PHP
   7.4,
   but I wouldn't expect new composer users to be aware of the ability to
   do that
   until they run into issues, and that doesn't help if A/A is a
   dependency of another package.

2. C/C 5.0 could exit() when bootstrapping when it's run in php 7,
   but that seems excessive and not currently done by libraries in my
   experience.

---

If a developer needs to backport code or patches for php 8.0+ to php 7.4
or older
(e.g. to support legacy applications or OSes that make updating php
impractical),
the lack of a syntax error would make this backporting error prone
if the developer didn't remember this incompatibility
or learn about tools created to catch issues.
(or didn't know about up-to-date, bug-free tools to downgrade php syntax)

---

For
https://wiki.php.net/rfc/shorter_attribute_syntax_change#machine_scanning_for_end_of_attribute_declaration
I'd agree that the lack of an ending delimiter makes token-based
extraction more complicated but still practical,
but it is a complexity that projects such as phpcs would already face in
similar syntaxes.
The problems with whitespace and comments and doc comments between tokens
can be fixed by filtering out whitespace and comments before/while looking
to the end of a token.
Projects such as nikic/php-parser or microsoft/tolerant-php-parser would
be what I'd recommend for new code/scripts,
but this is impractical for large existing codebases with third party
plugins such as phpcs.

A stack-based approach is used for @[ or #[.
A stack-based approach would also be used for @@Attribute /*comment */ (
by skipping T_WHITESPACE, T_COMMENT, and T_DOC_COMMENT and ending parsing
of that attribute if the next token isn't (.
Skipping whitespace and comments that way already needs to be done to
correctly find the end of the function call myGlobalFunction /* comment */ (args); (or new MyClass /* comment */ (args)).
For both function calls and attributes, I'd assume style guides would
forbid whitespace and comments before (.

Thanks,

• Tyson

Forcing @@ attributes to end with parenthesis?

I don't really see the point of this section in the RFC.

The blame for that is on me, not Benjamin and Derek, as I repeatedly asked
why a compulsory ) could not be considered a closing delimiter.

Attribute nesting

The RFC points out that all the syntaxes can allow attribute nesting,
which is true. However, it would be nice to include an example of
potential future nesting for each syntax, as was included in the
original Shorter Attribute Syntax RFC. The reason is that some of the
syntaxes are less readable than others when nested (particularly <<>>,
though arguably #[] and @[] as well since the attribute end
delimiter can be confused with the end bracket of an array argument.

@@JoinTable(
    "User_Group",
    @@JoinColumn("User_id", "id"),
    @@JoinColumn("Group_id", "id"),
)
private $groups;

#[JoinTable(
    "User_Group",
    #[JoinColumn("User_id", "id")],
    #[JoinColumn("Group_id", "id")],
)]
private $groups;

@[JoinTable(
    "User_Group",
    @[JoinColumn("User_id", "id")],
    @[JoinColumn("Group_id", "id")],
)]
private $groups;

<<JoinTable(
    "User_Group",
    <<JoinColumn("User_id", "id")>>,
    <<JoinColumn("Group_id", "id")>>,
)>>
private $groups;

@:JoinTable(
    "User_Group",
    @:JoinColumn("User_id", "id"),
    @:JoinColumn("Group_id", "id"),
)
private $groups;

Good catch.

Peter

On Mon, Aug 17, 2020 at 3:06 AM Theodore Brown theodorejb@outlook.com
wrote:

On Sun, Aug 16, 2020 at 4:36 AM Benjamin Eberlei kontakt@beberlei.de
wrote:

We have updated the RFC with all (hopefully) of the feedback from
this discussion:

https://wiki.php.net/rfc/shorter_attribute_syntax_change

Most notable changes are:

• A new section with several subsections on the benefits of a closing
  delimiter / enclosing syntax.
• A section on grouping pro/cons
• Inclusion of @: as per Theodores request

We are looking for further feedback from the community.

Hi Benjamin and Derick,

Thank you for taking the time to further flesh out the RFC and
include the @: syntax option. Overall it is a lot better now.
However, I still have some concerns with several claims in the RFC
that are inaccurate or incomplete, particularly in the "Discussion
on Ending Delimiter / Enclosing Delimiters" section. 1

The RFC intro says "we should strongly favor a syntax with closing
delimiter to keep consistency with other parts of the language". It
is then argued that "Many complex syntax constructs in PHP have an
ending delimiter", and therefore attributes should have one as well.

However, ending delimiters in PHP have little to do with how "complex"
a syntax construct is (which is a rather loose definition, anyway).
As I've pointed out before, standalone statements and declarations
generally require an end symbol, but modifiers before a declaration
do not. Attributes fall into the latter category, and therefore the
lack of an end delimiter is consistent.

A docblock is also a "modifier" under your declaration and it has an ending
symbol.

The RFC gives a definition of the complexity as just a token vs a set of
name, arugment_list and constant expression parser rules. It shows
an example porting an ORM\JoinTable Attribute, which has arguments, named
parameter usage, complex definitions of default values (Strings, arrays).

This piece of code probably touches 10-20 parser rules.

Most modifiers don't even have a parser rule, as they only match their
token.

The RFC responds to this counterargument with a series of four
claims, none of which is fully accurate in describing declaration
modifiers:

1. Even if we only consider keyword declaration modifiers, the claim
   that "these modifier keywords all have only exactly one token that
   can immediately follow them, T_WHITESPACE" is not correct. Just as
   with attributes, modifier keywords can also be followed by a comment
   token (#, //, or /**/):

    @@Attribute// some comment
    final// some comment
    class Foo {...}
   

Strangely, the RFC only lists keywords like public and final as
declaration modifiers, and neglects to mention that type declarations
are also in this category (which I have pointed out in all my
previous responses to this argument).

Type declarations can be not only followed by whitespace and comment
tokens, but also a T_VARIABLE token:

function foo(Type$bar) {}

2. The RFC goes on to claim that "[declaration modifiers] are all
   non-complex and are only made up of a handful ascii letters". Again,
   this fails to consider type declarations, which can contain the same
   non-ascii characters that attribute names can.

Types are missing indeed, and they are more complex than a simple token,
but less complex than attribute declarations.

I guess the difference is that union types are new, and type definitions
used to be simple. Attributes however are new
and already complex, so we still have the option of always enclosing them.

3. Next, the RFC says "these keywords are always on a single line".
   But union type declarations can be spread across multiple lines,
   and still don't have an end delimiter:

    function foo(
        \My\FullyQualified\ClassName
        |string $param
    ) {...}
   

4. Finally, the RFC says that "visibility keywords are only boolean
   or bitflags in Reflection, but Attributes are a full fledged
   ReflectionAttribute representing their own distinct language concept."
   You can probably guess where I'm going with this... Type declarations
   are likewise a fully fledged ReflectionType representing their own
   distinct language concept.

So the RFC's argument that attributes need to have a distinct ending
symbol for consistency is not convincing. The lack of an ending
delimiter is fully consistent with other declaration modifiers,
whether simple or complex.

Benefits for IDEs and editors?

The RFC suggests a benefit of "Consistent colouring for being an end
of the attribute syntax and the keywords in between can use different
colors." I don't really understand this argument. How would an end
delimiter change the syntax highlighting provided by IDEs?

If you consider the three elements of an attribute declaration: 1. Syntax
for Attributes 2. Atttribute Name 3. Arguments
then if you color them in three different ways, then with an ending symbol
it improves the human readability
to have the end be in the same color als the beginning.

Another suggested benefit is that IDEs can "Implement regions to
open/close the grouped declaration of one or multiple attributes."
But IDEs can still do this without an end delimiter, and groups of
attributes could even be opened/closed independently by separating
them with an empty line (which should improve readability for humans
as well).

Yes regions would be possible for a whole block of attributes with @@ as a
single block.
or when adding an empty line between them. But that completely detaches
attributes from the declaration
visually to have an empty line between them, so coding styles would
probably not allow that. With grouping and end delimiters
this is potentially easier and more flexible. I don't say this is a
particularly important argument, but there is a difference.

We are getting flak for not including the littelest argument in this RFC,
even though many things are quite obvious.

if we are going for completeness then I am going to write literally
everything down.

Easier machine parsing?

The RFC shows a list of different ways that attributes with the @@
syntax can end, and claims "This makes programmatic token based
scanning for attribute syntax without a closing delimiter such as @@
unnecessarily complicated."

But I've worked with userland token stream scanners myself, and it's
not difficult to skip T_WHITESPACE and T_COMMENT tokens. Once you do
that, parsing an attribute is as simple as finding any T_ATTRIBUTE
token followed by the name token, then checking for an optional
argument list. If there's not an argument list, that's then end of
the attribute, otherwise the end is the end of the argument list.

With the @[] and #[] syntaxes, a userland token parser is actually
more complex due to grouping. It not only has to do the same things
listed above, but it also has to check whether there are multiple
comma-separated attributes between the start/end delimiters (making
sure not to confuse a comma-separated attribute with a comma-separated
argument, or the end of an array argument with the attribute end
delimiter).

So I don't understand how the RFC can claim that attributes without
an end symbol "introduce additional complexity" for machines, when if
anything the opposite is true.

(And don't get me started about the extra difficulty for token stream
scanners with the <<>> syntax which has no T_ATTRIBUTE token).

Forcing @@ attributes to end with parenthesis?

I don't really see the point of this section in the RFC. What issue
would forcing an end parenthesis solve? And what does whitespace
between the attribute name and argument list have to do with anything?
Such whitespace is allowed with all of the proposed syntaxes.

I included this section because multiple people (Peter, Rowan, + more i
believe) suggested this as a compromise to keep @@ but fix the issues of
not having an ending delimiter.

The example shows how it does not guarantee an attribute could be scanned
as a whole block, due to the fact that you can have whitespaces in there.

I do agree, though, that requiring an end parenthesis for @@ would
be inconsistent with object instantiation - that's one of the main
reasons I didn't require it in the Shorter Attribute Syntax RFC.

Exactly

Potential Future Benefits of Enclosed Delimiter Syntax?

The RFC shows an example of a potential "simpler" attribute using a
string instead of a class name. I honestly have no idea what this is
supposed to do or what benefit it would have over normal attributes.

The concept of attributes being a class name with optional arguments
has been proven over many years by its use in docblock annotations,
and if there was some deficiency in what this syntax allows it seems
like we would have discovered it by now.

I agree on just the string, but a closure would make 100% sense for a
decorating
feature. Javascript and Python "Attributes" work as decorators, i.e. they
get called around the decorated function.

It is not a completely unrealistic feature to think off:

@[fn($x) => syslog(LOG_INFO, "Called function foo with x: " . $x)]
function foo($message) {}

Attribute nesting

The RFC points out that all the syntaxes can allow attribute nesting,
which is true. However, it would be nice to include an example of
potential future nesting for each syntax, as was included in the
original Shorter Attribute Syntax RFC. The reason is that some of the
syntaxes are less readable than others when nested (particularly <<>>,
though arguably #[] and @[] as well since the attribute end
delimiter can be confused with the end bracket of an array argument.

@@JoinTable(
    "User_Group",
    @@JoinColumn("User_id", "id"),
    @@JoinColumn("Group_id", "id"),
)
private $groups;

#[JoinTable(
    "User_Group",
    #[JoinColumn("User_id", "id")],
    #[JoinColumn("Group_id", "id")],
)]
private $groups;

@[JoinTable(
    "User_Group",
    @[JoinColumn("User_id", "id")],
    @[JoinColumn("Group_id", "id")],
)]
private $groups;

<<JoinTable(
    "User_Group",
    <<JoinColumn("User_id", "id")>>,
    <<JoinColumn("Group_id", "id")>>,
)>>
private $groups;

@:JoinTable(
    "User_Group",
    @:JoinColumn("User_id", "id"),
    @:JoinColumn("Group_id", "id"),
)
private $groups;

I wanted to skip adding this, because the RFC is already so long and this
is really sometihng that everyone can make up in their mind thinking about
it. I agree that with <<>> the nested syntax would be hard to stomach, but
for @@, @[] and #[] it is just using the same syntax that you prefer or not
prefer.

With appreciation,
Theodore

On Mon, Aug 17, 2020 at 10:59 AM Alexandru Pătrănescu drealecs@gmail.com
wrote:

On Sun, Aug 16, 2020 at 12:36 PM Benjamin Eberlei kontakt@beberlei.de
wrote:

We have updated the RFC with all (hopefully) of the feedback from this
discussion:

https://wiki.php.net/rfc/shorter_attribute_syntax_change

Most notable changes are:

• A new section with several subsections on the benefits of a closing
  delimiter / enclosing syntax.
• A section on grouping pro/cons
• Inclusion of @: as per Theodores request

We are looking for further feedback from the community.

Thanks for the work. Looks good.
An idea.

Would the syntax @<Attr> be able to obtain a "No" on the "Breaks BC of
valid PHP 7 code" section while still being more or less the same as
#[Attr] or @[Attr] considering other features?
BTW, I'm thinking that it's good to have a "No" there.

Sorry if proposing another syntax is making this an even more complex
problem.

It is ok to propose another syntax, at this point in time we are working
around the @ and [] symbols, because of their familiarity with other
languages attribute syntax.

There is probably 100 potential syntaxes that we could use, @<> is a bit
hard on the eyes as is <<>>, so i wouldn't call it a game changer in
contrast to what we have already, so I would rather not include it.

Regards,
Alex

Hi,

Out of Banjamin's suggestion[1], I've updated the Shorter Attribute
Syntax Change RFC to reflect that process:

https://wiki.php.net/rfc/shorter_attribute_syntax_change

Patches and comments welcome.

FWIW, this has an excemption from the RM Sara as per [2]:

• Shorter Attribute Syntax Change
  • Joe/Derick - Please make sure this RFC moves along and reaches
    conclusion by beta3, as discussed previously.

cheers,
Derick

[1] https://externals.io/message/111218#111261
[2] https://externals.io/message/111286#111286

--
PHP 7.4 Release Manager
Host of PHP Internals News: https://phpinternals.news
Like Xdebug? Consider supporting me: https://xdebug.org/support
https://derickrethans.nl | https://xdebug.org | https://dram.io
twitter: @derickr and @xdebug

--

To unsubscribe, visit: https://www.php.net/unsub.php

possibility to keep @@ and add @{} as a second syntax for attributes

+1, but I would keep same prefix, ie. @@{} (or @@[]), for both syntaxes,
it is much easier for human eyes to search for one thing, also easier
for grep

With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,

Michael Voříšek

As a possible addition/discussion point, I only noticed today that @{}
is a syntax that has not been mentioned yet, also not in any previous
discussions about attributes as far as I can tell. @{} currently leads
to a syntax error, so there is no BC break, and {} is common syntax for
grouping expressions in PHP, much more so than [], which is an
array-specific syntax.

Would it be a possibility to keep @@ and add @{} as a second syntax for
attributes, that can be used for grouping (for situations where that
makes sense) or other possibly future extensions? Then @@ would be a
good syntax for simple attribute definitions, and @{} could be an
alternative for people who want to group them or if any more complex
attribute features are added to the language later.

Because both sides of the "ending delimiter or no ending delimiter"
discussion do have some points in their favor, and it seems quite
individual what each person prefers. For a language it could be
beneficial to give some choices to the developer instead of foreseeing
each individual use case, and maybe attributes is such a feature.

I previously thought about suggesting both types of syntax (with and
without delimiters), but felt the current options all have too many side
effects to choose "two side effects" or two BC breaks. But the @@ BC
break seems the most harmless BC break of the bunch, and @{} does not
have a BC break, so these two option might be good together.

--

To unsubscribe, visit: https://www.php.net/unsub.php

On Sun, Aug 16, 2020 at 11:36 AM Benjamin Eberlei kontakt@beberlei.de
wrote:

We have updated the RFC with all (hopefully) of the feedback from this
discussion:

https://wiki.php.net/rfc/shorter_attribute_syntax_change

Most notable changes are:

• A new section with several subsections on the benefits of a closing
  delimiter / enclosing syntax.
• A section on grouping pro/cons
• Inclusion of @: as per Theodores request

We are looking for further feedback from the community.

From the updated RFC:

There are multiple reasons why we believe the previous vote should be
revisited:

Ok, bring it on!

At the point of the vote for @@, it was not clear that the syntax
required the namespace token RFC to be viable.
While this is not a problem anymore, the @@ syntax might not have come
out on top if this information was known beforehand.

If anything, this is an argument AGAINST this RFC. A "bad" decision
was taken. The problem with it was fixed. No need to change anything.
The argument comes across as disingenuous, I'm afraid.

And then boo-yah, 6 months later we want to implement a cool new feature to
attributes (a lot of examples were said before, ain't repeating myself) but
we can't :(( because there is no ending delimiter and thus, we will run
into parsing issues.

Moving on...

The #[] syntax provides the benefit of forward compatibility, but this
also introduces some potential problems for PHP 7 code.
An alternative syntax @[] was suggested to eleviate these problems which
was not previously voted on.

Ok, let's analyze the logic here as well: #[] lost the vote. #[] would
have had some problems. Are there any

What problems? Besides the BC breaks that all of the syntaxes (except
<<...>>) have, there are no problems.

syntaxes we still haven't voted

on? Yes!
Come on...

And lastly...

We argue why we should strongly favor a syntax with closing delimiter to
keep consistency with other parts
of the language and propose to use #[], @[], or the original << … >>
instead.

This is the only part that contains logically valid arguments, albeit
most are subjective and speculative. Which is not to say it's not
worth voting on them.
But looking for actual facts, I only came across only this little cutie:

For VIM users, the % operation to jump between opening and closing part
of declaration that would automatically work with [ and ].
I fully expect all 3 VIM users to vote in favor of this RFC ;-)

Ok, enough of my sarcasm - I only wish you'd put your strongest
arguments first and focused on quality over quantity.

I wish someone actually gave reasonable arguments as to why @@ is better.
Because a) no one cares if we have to type 2 or 3 characters b) @@ does
not ensure 100% safe future c) it does not decrease complexity in any way.

• Jakob

--

To unsubscribe, visit: https://www.php.net/unsub.php

On Wed, Aug 19, 2020 at 12:03 AM Theodore Brown theodorejb@outlook.com
wrote:

On Tue, Aug 18, 2020 at 1:00 PM Benjamin Eberlei kontakt@beberlei.de
wrote:

https://wiki.php.net/rfc/shorter_attribute_syntax_change

I have updated the RFC one last time with as much of the feedback
as possible:

• a section about comparing to complexity of type definitions
• removal of the machine reading section as too narrow and
  ultimately not that important as downstream libraries just have to
  deal with any of it
• some more nuances in forward compatibility pro/cons section of #[]
• smaller corrections and improvements.

I don't think something major is missing now.

Hi Benjamin,

Thanks for the updates. I just have a few more thoughts on aspects
that haven't been mentioned before:

1. The Attributes are not like Modifiers section makes an
   argument that having an end delimiter "groups docblock comment and
   attributes into two similarly shaped syntax blocks that prefix the
   declaration increasing familiarity."

In my own (admittedly subjective) opinion, an end delimiter on
attributes actually increases confusion when there is also a
docblock. To reuse the example from the RFC:

/**
 * A comment describing things.
 *
 * @psalm-suppress SomeRule
 */
#[
    ORM\Entity(),
    ORM\Table("baz")
]
final class Something {
}

Because the attribute group has its own start and end delimiters, it
almost looks like the doc comment applies to the attribute block
rather than the class.

With the @@ or @: syntax, it seems clearer that attributes are
part of the class/function/property declaration, rather than their
own standalone construct which docblocks can be applied to:

/**
 * A comment describing things.
 *
 * @psalm-suppress SomeRule
 */
@@ORM\Entity
@@ORM\Table("baz")
final class Something {
}

Given that the only complex part of an attribute is the optional
argument list, which already has its own start/end delimiters, I
ultimately don't find the "complexity" argument very compelling for
needing an additional attribute end delimiter besides.

2. In the Discussion on grep'ability section, the RFC says
   "Enforcement of same line is also not the case for other
   declarations that benefit from grep'ability such as classes,
   functions, constants and so on in PHP already, so this is not
   consistent within the language."

This seems to be outdated information, based on Martin's original
patch before the "Treat namespaced names as single token" RFC was
accepted. In the current @@ implementation, there is no single-line
enforcement, consistent with other parts of the language.

Right, i didn't realize this restriction was lifted and updated this
section.

This doesn't change the argument though that when you need coding styles to
enforce a particular style that grepability works, then you can find a
coding standard with all syntaxes that has good grepability, i.e. by not
using grouping.

Not having whitespace between the attribute token and name would be
enforced by coding style conventions, just as is the case with
function/class/constant definitions.

Note that there is some precedent in PHP for choosing syntax that
ensures easier searching (for example, the decision to place return
type declarations after the parameter list rather than before the
function name).

Grep'ability isn't a big deal when finding usages in an IDE, but
sometimes there is a need to search code on a server or other source
without an IDE, in which case easy grep'ability can be very helpful.

Sincerely,
Theodore

Just to mention something here in a bit more depth because it is easy to
overlook in the RFC if you have looked at it a lot.

In "Potential Future Benefits of Enclosed Delimiter Syntax" there is an
addition of an example using an attribute for an AOP-style
before-function callback:

 @:Before(fn ($x) => $x*4)

IMO this is much more readable and self-documenting than a dangling
lambda like @[fn ($x) => %x*4], as the attribute name hints at what is
going on, and it provides enclosure with the arg list ().

I read a lot of code I didn't write, and I like your example. It is much
more readable and self-documenting.

Peter

One last change that I didn't see yesterday as it was on Github and not
this list is the addition of another syntax proposal @{} with the same
benefits as @[], a little more snowflake than compared to other languages,
but without the BC Break.

I mentioned the benefits of @{} in an email to this list on Monday, with
the proposal to have both @@ and @{} as attribute syntax, so both camps
could have their syntax (one with delimiters, one without) with minimal
BC breaks, and leave the decision to the PHP developers/projects what
they prefer in what circumstances, because there can be valid reasons to
use both - I probably would use both. @{} could be good to define
multiple attributes for classes/properties, @@ could be good for short
attributes or ones very entrenched within the code, like function
parameters. The @{} syntax could be amended in the future, so this would
also be "future-proof".

But I guess the division about syntax is too big at this point to
consider an approach where we just offer both types of syntax. From a
PHP developer viewpoint, it would be preferable though.

Please add discussion about merge conflicts. Any inline grouped
attribute syntax needs a manual conflict resolution.

With ungrouped syntax, I expect recommended CS to be one attribute per
line.

If this should be the case also for grouped syntax, then it not +1
character, but +2 new lines per every annotated element.

Also, is 2/3 majority required by RFC rules satisfied by the "Are you
okay with re-voting on the attribute syntax for PHP 8.0, again?"
question?

I think we should require 2/3 votes at least on the question if we
should allow grouping or not and if accepted, use STV results on the
prefered prefix symbols/syntax.

With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,

Michael Voříšek

On Tue, Aug 18, 2020 at 8:00 PM Benjamin Eberlei kontakt@beberlei.de
wrote:

Hi,

Out of Banjamin's suggestion[1 [1]], I've updated the Shorter Attribute
Syntax Change RFC to reflect that process:

https://wiki.php.net/rfc/shorter_attribute_syntax_change

Patches and comments welcome.

FWIW, this has an excemption from the RM Sara as per [2 [2]]:

• Shorter Attribute Syntax Change

• Joe/Derick - Please make sure this RFC moves along and reaches
  conclusion by beta3, as discussed previously.
  Heads up: This RFC is now going to vote tomorrow:

https://wiki.php.net/rfc/shorter_attribute_syntax_change

I have updated the RFC one last time with as much of the feedback as
possible:

• a section about comparing to complexity of type definitions
• removal of the machine reading section as too narrow and ultimately
  not
  that important as downstream libraries just have to deal with any of it
• some more nuances in forward compatibility pro/cons section of #[]
• smaller corrections and improvements.

I don't think something major is missing now.

One last change that I didn't see yesterday as it was on Github and not
this list is the addition of another syntax proposal @{} with the same
benefits as @[], a little more snowflake than compared to other
languages,
but without the BC Break.

cheers,
Derick

[1] https://externals.io/message/111218#111261
[2] https://externals.io/message/111286#111286

--
PHP 7.4 Release Manager
Host of PHP Internals News: https://phpinternals.news
Like Xdebug? Consider supporting me: https://xdebug.org/support
https://derickrethans.nl | https://xdebug.org | https://dram.io
twitter: @derickr and @xdebug

--

To unsubscribe, visit: https://www.php.net/unsub.php

Links:

[1] https://externals.io/message/111218#111261
[2] https://externals.io/message/111286#111286