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

http://ocramius.github.com/

Hi all,

I know we've voted twice on this already, but are we really sure that
the @@ syntax is a good idea?

Pretty much clear that @@ is a bad choice - it was picked due to
familiarity of some folks with java annotations,
but it is clear that rust-ish annotations with a clear delimiter have
technical advantages in parsing and future scope/support.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Am 22.07.2020 um 14:00 schrieb Derick Rethans:

Please, let's do the sensible and use the Rusty #[...] syntax.

+1

Also, +1. I don't really care whether we switch back to <<...>> or
#[...] but I think @@ was a bad choice and thus, I think it would be a
much more sensible decision to change the syntax again. At least for the
sake of not running into new ambiguities and in order to stay more similar
with other languages.

Hi all,

I know we've voted twice on this already, but are we really sure that
the @@ syntax is a good idea?

• There are lots of grumbles, both on here, room 11, as well as in the
  wider community (https://www.reddit.com/r/PHP/comments/hjpu79/it_is/)
• It has the distinct possibility to cause further parsing issues, akin
  to what ended up happening with what Nikita is addressing at
  https://wiki.php.net/rfc/namespaced_names_as_token
• There is no "end symbol" to make finding occurences easier.
• It is a syntax no other language uses.
• @ is never going to go away, so the possibility of @@ moving to @ is
  also 0.

Please, let's do the sensible and use the Rusty #[...] syntax.

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

--

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

Hi Derick,

śr., 22 lip 2020 o 14:00 Derick Rethans derick@php.net napisał(a):

Hi all,

I know we've voted twice on this already, but are we really sure that
the @@ syntax is a good idea?

• There are lots of grumbles, both on here, room 11, as well as in the
  wider community (https://www.reddit.com/r/PHP/comments/hjpu79/it_is/)
• It has the distinct possibility to cause further parsing issues, akin
  to what ended up happening with what Nikita is addressing at
  https://wiki.php.net/rfc/namespaced_names_as_token
• There is no "end symbol" to make finding occurences easier.
• It is a syntax no other language uses.
• @ is never going to go away, so the possibility of @@ moving to @ is
  also 0.

Please, let's do the sensible and use the Rusty #[...] syntax.

I agree with all the above arguments.

Is there a place (before feature-freeze) and a way to revote it?
What should be the procedure then?
Does it mean the RFC process has an issue and how could it be fixed?

Cheers,
Michał

"Terrible" is the amount of humans having their lives taken by a pandemic.
This is at most slightly inconvenient for you. The aggressive tone in this
discussion is extremely unnecessary.

Hi all,

I know we've voted twice on this already, but are we really sure that
the @@ syntax is a good idea?

• There are lots of grumbles, both on here, room 11, as well as in the
  wider community (https://www.reddit.com/r/PHP/comments/hjpu79/it_is/)
• It has the distinct possibility to cause further parsing issues, akin
  to what ended up happening with what Nikita is addressing at
  https://wiki.php.net/rfc/namespaced_names_as_token
• There is no "end symbol" to make finding occurences easier.
• It is a syntax no other language uses.
• @ is never going to go away, so the possibility of @@ moving to @ is
  also 0.

Please, let's do the sensible and use the Rusty #[...] syntax.

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

--

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

--
Marco Aurélio Deleu

Hi,

Hi all,

I know we've voted twice on this already, but are we really sure that
the @@ syntax is a good idea?

I agree that @@ is really bad. Personally I'd prefer <<...>> but #[...]
seems fine as well (although it's a minor BC break as there could be a
valid comment). I think there are more people that are fine with both
<<...>> and #[...] but don't like @@. Maybe having an option to vote for
more options would be more suitable here or something where it's possible
to vote against @@ rather than just pick one option.

Cheers

Jakub

Le Wed, 22 Jul 2020 13:00:10 +0100 (BST),
Derick Rethans derick@php.net a écrit :

Please, let's do the sensible and use the Rusty #[...] syntax.

This syntax is the one I liked the less in the proposed choices, given # is
used for comments.

Wouldn’t #[] cause more parsing issues than @@?

What would be the rule, it’d be illegal to start a comment content with '['?

Côme

+1

El mié., 22 jul. 2020 a las 9:00, Derick Rethans (derick@php.net)
escribió:

Hi all,

I know we've voted twice on this already, but are we really sure that
the @@ syntax is a good idea?

• There are lots of grumbles, both on here, room 11, as well as in the
  wider community (https://www.reddit.com/r/PHP/comments/hjpu79/it_is/)
• It has the distinct possibility to cause further parsing issues, akin
  to what ended up happening with what Nikita is addressing at
  https://wiki.php.net/rfc/namespaced_names_as_token
• There is no "end symbol" to make finding occurences easier.
• It is a syntax no other language uses.
• @ is never going to go away, so the possibility of @@ moving to @ is
  also 0.

Please, let's do the sensible and use the Rusty #[...] syntax.

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

--

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

I know we've voted twice on this already, but are we really sure that
the @@ syntax is a good idea?

No, no we are not.

We've already found one gaping hole in it, we will likely find more. Why
knowingly back ourselves into a corner when there are perfectly good
alternatives?

Mark Randall
marandall@php.net

Hi all,

I know we've voted twice on this already, but are we really sure that
the @@ syntax is a good idea?

• There are lots of grumbles, both on here, room 11, as well as in the
  wider community (https://www.reddit.com/r/PHP/comments/hjpu79/it_is/)
• It has the distinct possibility to cause further parsing issues, akin
  to what ended up happening with what Nikita is addressing at
  https://wiki.php.net/rfc/namespaced_names_as_token
• There is no "end symbol" to make finding occurences easier.
• It is a syntax no other language uses.
• @ is never going to go away, so the possibility of @@ moving to @ is
  also 0.

Please, let's do the sensible and use the Rusty #[...] syntax.

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

--

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

Hello Derick.

I do understand your concerns, and I appreciate that you've reached out.

Although we are very close to the Feature Freeze date for PHP 8.0 (
https://wiki.php.net/todo/php80), I wouldn't mind opening an exception for
this specific case and let you (or someone), create an RFC proposing to
change the syntax of Attributes (https://wiki.php.net/rfc/attributes_v2),
and that only!

I'm copying PHP 8.0's Release Manager Sara, to hear her opinion on this as
well.

-- Gabriel Caruso

I know we've voted twice on this already, but are we really sure that
the @@ syntax is a good idea?

• There are lots of grumbles, both on here, room 11, as well as in the
  wider community (https://www.reddit.com/r/PHP/comments/hjpu79/it_is/)
• It has the distinct possibility to cause further parsing issues, akin
  to what ended up happening with what Nikita is addressing at
  https://wiki.php.net/rfc/namespaced_names_as_token
• There is no "end symbol" to make finding occurences easier.
• It is a syntax no other language uses.
• @ is never going to go away, so the possibility of @@ moving to @ is
  also 0.

Please, let's do the sensible and use the Rusty #[...] syntax.

Hi Derick,

Most of the comments in that Reddit thread appear to be positive or
neutral, and in the earlier community poll, the @@ syntax received by
far the most votes (https://www.reddit.com/r/PHP/comments/h06bra/community_poll_attribute_syntax/).
So while some in the community may prefer a different syntax, this
doesn't seem to reflect the majority.

If @@ actually has parsing issues, then I would agree that we need to
pick another syntax. But there aren't any issues following Nikita's
RFC to treat namespaced names as tokens. Please check out the
implementation and let me know if you find any problems:
https://github.com/php/php-src/pull/5796.

While most would like to have a single @ character for attributes,
since this isn't possible @@ is the closest alternative, and it
shouldn't present any parsing issues that wouldn't also affect a
single @ character. Of course it will always be possible to think of
theoretical ambiguities with unconventional future syntax, but in
practice this hasn't been an issue for the many other languages using @.

One of the benefits of @@ is actually making it easier to find
occurrences. <<>> is problematic here since these characters also
occur in heredocs/nowdocs and bit shifts. And the ending bracket of
#[] is also used for arrays, so it's not clear that this is very
helpful, either.

The benefit of #[] being exactly the same as another language was
considered in the Shorter Attribute Syntax RFC, but apparently most
voters didn't feel that this outweighed the downsides of a larger BC
break, extra verbosity, and possible confusion with comments.

If there isn't an actual technical problem with the implementation, I
don't think it would be appropriate to hold another vote, or discard
the first preference vote of all those who preferred the @@ syntax.

Best regards,
Theodore

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

Hi!

I know we've voted twice on this already, but are we really sure that
the @@ syntax is a good idea?

I think it's not a very good idea, and <<>> was just fine, but a lot of
folks apparently voted for it. Would be nice to see their opinion and
how they answer your concerns. I'm not sure it's proper to override the
vote unless there are some severe technical concerns that make that
choice impossible.

--
Stas Malyshev
smalyshev@gmail.com

I know we've voted twice on this already, but are we really sure that
the @@ syntax is a good idea?

Yes. Because we voted on it. Twice.

• It has the distinct possibility to cause further parsing issues, akin
  to what ended up happening with what Nikita is addressing at
  https://wiki.php.net/rfc/namespaced_names_as_token

Citation Needed.

The '@' token and the T_DOUBLE_AT token come from the lexer as distinct
values, where is the conflict?

I'm not doubting that there is one, you're quite clever, but at the moment
you're stating facts not currently in evidence.

• There is no "end symbol" to make finding occurences easier.

• It is a syntax no other language uses.

• @ is never going to go away, so the possibility of @@ moving to @ is
  also 0.

We knew each of these points at the time of voting. This is not new
information.

Please, let's do the sensible and use the Rusty #[...] syntax.

Remoaner. (j/k, you know I love you)

I'm fine with this or any syntax, but FF is 13 days away, you're going to
have to give me something more substantial than "It maybe breaks something
somewhere somehow".

-Sara

• There are lots of grumbles, both on here, room 11, as well as in the
  wider community (https://www.reddit.com/r/PHP/comments/hjpu79/it_is/)

From discussions in R11 I want to offer the following example of why
either option with a closing tag is preferable to allow maximum
flexibility in future development.

Assume we want to extend attributes to include something a lot of PHP
features have, an access scope, to only allow accessing annotations from
within the class itself, or a descendant.

Then we end up with something like :

class Foo {
@@protected Attr protected int $bar;
}

Contrast that to something with opening and closing tags where they are
clearly grouped:

class Foo {
#[protected Attr] protected int $bar;
}

What other syntax might we want to add? Perhaps we want to add a way to
enforce validation at encounter time with a "checked" keyword.

@@checked protected Attr(1,2,3) protected int $bar

#[checked protected Attr(1,2,3)] protected int $bar

It's much less ambiguous what belongs to what.

Now we could dig ourselves out of this hole using additional tokens
around @@ such as @@(checked protected Attr) but at which point why not
just use a mechanism that supports it out of the box?

Mark Randall

To be clear, is there anyone who voted for @@ and changed his mind based on new
information?
Please see the initial discussion here:

https://externals.io/message/110568#111038

Hi

Regards the vote; I don't believe that @@ has been proven unworkable,
however if I'm wrong about that, then the second choice selection from the
last vote would obviously take precedence.

I don't believe the concern is that we have something unworkable sitting
in front of us right now, after all if that were the case we would not
be needing to have this conversation as the RFC would already have been
rendered void.

What we do have, is a deep sense of unease that we collectively made the
wrong decision, based on, in part, incomplete information.

While the initial block to @@ has been remedied by a larger
language-level change, that the problem existed at all provided a clear
example of the widely unforeseen challenges associated with the @@
syntax and its lack of closing tags, and focused renewed attention on
long-term consequences which where perhaps not given enough
consideration during the vote.

There has been one occurrence already, there will likely be more in the
future. But what specifically will they be and how severe? We likely
will not know until they happen.

Hi Mark,

I don't agree that there "will likely be more in the future". When I
asked Nikita if he could think of any example that would end up being
a problem, the only one he listed was a infinite parser lookahead
requirement if a) attributes were allowed on statements and b)
generics were implemented with curly braces instead of angle brackets.

He noted that "it's unlikely we'd actually do that" and ended his
email by saying "it is more likely than not, that we will not
encounter any issues of that nature." [1]

The @ attribute syntax has been used in other C family languages for
years, and to my knowledge hasn't caused any problems in practice.

It is actually the <<>> variant that is more likely to back us into a
corner when it comes to future syntax like nested attributes (the RFC
authors considered it to cross a line of unacceptable ugliness,
and the alternative new Attribute syntax has technical problems).
This may be one reason Hack is moving away from it to @.

But what we can say with reasonable confidence is we have an option
on the table that is technically superior

I don't agree that #[] is technically superior. The implementation is
virtually identical. The main practical difference is that hash
comments could no longer start with a [ character, which would be
surprising behavior and a larger BC break (there's definitely code in
the wild using this right now).

If you have a concrete example of syntax that is likely to cause a
problem with @@, please share it. From my perspective, @@ is closest
to the syntax used by the majority of C family languages for
attributes, and thus is least likely to present future challenges.

Best regards,
Theodore

I was going to reply these same things, but you beat me to it. But just to
complement, after looking at the patches it became a bit evident that
most of the concerns being raised against @@ also work against the
other proposals. All have a certain level of BC break due to parsing
ambiguity:

• @@ can break the silence operator when it's chained (useless anyway)
• #[...] breaks comments
• <<...>> has problems with bit shift operators

From all these tradeoffs I'd rather compromise on breaking the useless
chaining of error suppression operators, FOR SURE.

I have the impression most of this thread at this point is about personal
taste on what was voted rather than technical. Hopefully it's a wrong
impression.

[1]: https://externals.io/message/110568#111053

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

Ty,
Márcio

If that's the case, then the solution still seems obvious: Defer
attributes to 8.1.

After some discussion off list, including Nikita (who is probably closer
to this "problem" than any of the rest of us), I think the best way forward
at the moment is to proceed with the voted on action: Merge attributes
using @@ syntax prior to the feature freeze date.

However, with my RM hat on, I need to feel like we're as sure as we can be
about this syntax before it's public.
I'm willing to extend an additional period (up to the tagging of beta3, in
just under six weeks) for a re-vote on the syntax as changing that will be
less violent of a change than merging the entire implementation after
branching.

I hope this solution is both procedurally appropriate and satisfactory to
all.

-Sara