[RFC] [VOTE] Shorter Attribute Syntax

Ben Ramsey

6 years ago

> On Jun 17, 2020, at 18:59, Theodore Brown <theodorejb@outlook.com> wrote:
>
> Hi internals,
>
> I've opened voting on the Shorter Attribute Syntax RFC:
> https://wiki.php.net/rfc/shorter_attribute_syntax
>
> Since all RFCs require a primary vote with a 2/3 majority, there is
> a main vote to approve the secondary ranked-choice vote.
>
> For the ranked-choice poll, fill in your first through third syntax
> choices, making sure not to select the same syntax more than
> once. You don't have to vote for all three options, but please
> don't leave gaps.
>
> Voting will end in two weeks, on 2020-07-01.

I don’t understand this question:

> Are you okay with re-voting on the attribute syntax for PHP 8.0?

Is this a vote to see if we want to re-vote on the attribute syntax? I
think this is worded awkwardly, and I’m not sure what the outcome of a
yes or not vote means for this question.

If I vote “no,” should I still vote in the secondary vote, or is voting
“no” effectively the same as choosing `<<>>` for all three choices in
the secondary vote?

Or, if I vote “no,” does that mean anything I select for the secondary
vote is thrown out?

Cheers,
Ben

Derick Rethans

6 years ago

On Wed, 17 Jun 2020, Ben Ramsey wrote:

> > On Jun 17, 2020, at 18:59, Theodore Brown <theodorejb@outlook.com> wrote:
> >
> > I've opened voting on the Shorter Attribute Syntax RFC:
> > https://wiki.php.net/rfc/shorter_attribute_syntax
> >
> > Since all RFCs require a primary vote with a 2/3 majority, there is
> > a main vote to approve the secondary ranked-choice vote.
> >
> > For the ranked-choice poll, fill in your first through third syntax
> > choices, making sure not to select the same syntax more than once.
> > You don't have to vote for all three options, but please don't leave
> > gaps.
> >
> > Voting will end in two weeks, on 2020-07-01.
>
> I don’t understand this question:
>
> > Are you okay with re-voting on the attribute syntax for PHP 8.0?
>
> Is this a vote to see if we want to re-vote on the attribute syntax? I
> think this is worded awkwardly, and I’m not sure what the outcome of a
> yes or not vote means for this question.
>
> If I vote “no,” should I still vote in the secondary vote, or is
> voting “no” effectively the same as choosing `<<>>` for all three
> choices in the secondary vote?

> Or, if I vote “no,” does that mean anything I select for the secondary
> vote is thrown out?

You should vote in all four polls. If you choose "no" in the first one,
you might still have a preference for the syntax in case the outcome is
a "yes".

For your syntax preference, you can't pick the same option more than
once. This is ranked voting.

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

Sara Golemon

6 years ago

On Wed, Jun 17, 2020 at 7:23 PM Ben Ramsey <ben@benramsey.com> wrote:

> I don’t understand this question:
>
> > Are you okay with re-voting on the attribute syntax for PHP 8.0?
>
> I recommended this as a front-line question so as to remove any hint of

impropriety about the vote.  For example, where the first round of the
secondary vote sits right now (15/15/4) we only have 44% in favor of any
specific change.  That doesn't nearly meet the 2/3rd requirement.  By
having a "pre-vote" to agree on reselecting the syntax, we have a CLEAR
2/3rd majority saying, "Yes, let's revisit this specific question again".

With that clarified, making the decision on what specific syntax we want is
less contentious.  I had *hoped* that we wouldn't have a party split on the
primary vote, that people who wanted <<>> would still favor a
reconfirmation of the syntax since it was specifically cited that this
would be a point to come back to, but atm that's how things turned out.

Is this a vote to see if we want to re-vote on the attribute syntax? I

> think this is worded awkwardly, and I’m not sure what the outcome of a
> yes or not vote means for this question.
>
> Yeah, the wording is awkward, but so is the situation. /shrug

I hope the above clarifies it.

> If I vote “no,” should I still vote in the secondary vote, or is voting
> “no” effectively the same as choosing `<<>>` for all three choices in
> the secondary vote?
>
> On the primary, you should vote yes if you believe it's worth revisiting

the topic, or no if you feel the people have spoken and alligator syntax
means alligator syntax.
Regardless of primary vote: You should vote on the secondary according to
your preference of syntaxes.

-Sara

Benjamin Eberlei

6 years ago

On Thu, Jun 18, 2020 at 1:59 AM Theodore Brown <theodorejb@outlook.com>
wrote:

> Hi internals,
>
> I've opened voting on the Shorter Attribute Syntax RFC:
> https://wiki.php.net/rfc/shorter_attribute_syntax
>
> Since all RFCs require a primary vote with a 2/3 majority, there is
> a main vote to approve the secondary ranked-choice vote.
>
> For the ranked-choice poll, fill in your first through third syntax
> choices, making sure not to select the same syntax more than
> once. You don't have to vote for all three options, but please
> don't leave gaps.
>
> Voting will end in two weeks, on 2020-07-01.
>

Thank you for working on this RFC. The syntax question for Attributes is a
really hot topic and I think it is a good idea to have a re-vote with more
varied options than before.

The two new options now proposed didn't even cross my and Martin's mind for
the original RFC, because we strictly looked at syntaxes with no BC breaks.
Both @@ and #[] introduce very small, but also easily detectable and
fixable (via grep + sed or tools of choice).

A.L.E.C

6 years ago

On 18.06.2020 01:59, Theodore Brown wrote:

> Hi internals,
>
> I've opened voting on the Shorter Attribute Syntax RFC:
> https://wiki.php.net/rfc/shorter_attribute_syntax

If @@ wins, will a sequence of 3-or-more @ characters forbidden? It is
not stated in the RFC. I.e. what happens if you write:

@@@ExampleAttribute()
class Foo
{
}

@@@some_function();

--
Aleksander Machniak
Kolab Groupware Developer        [https://kolab.org]
Roundcube Webmail Developer  [https://roundcube.net]
----------------------------------------------------
PGP: 19359DC1 # Blog: https://kolabian.wordpress.com

Theodore Brown

6 years ago

On Thu, June 18, 2020 at 7:40 AM Aleksander Machniak <alec@alec.pl> wrote:

> If @@ wins, will a sequence of 3-or-more @ characters forbidden?
> It is not stated in the RFC. I.e. what happens if you write:
>
>     @@@ExampleAttribute()
>     class Foo
>     {
>     }
>
>     @@@some_function();

Hi Aleksander,

Yes, those examples would be syntax errors if the `@@` proposal is
accepted.

Regards,
Theodore

________________________________________
From: Aleksander Machniak <alec@alec.pl>
Sent: Thursday, June 18, 2020 7:40 AM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] [VOTE] Shorter Attribute Syntax

On 18.06.2020 01:59, Theodore Brown wrote:

> Hi internals,
>
> I've opened voting on the Shorter Attribute Syntax RFC:
> https://wiki.php.net/rfc/shorter_attribute_syntax

If @@ wins, will a sequence of 3-or-more @ characters forbidden? It is
not stated in the RFC. I.e. what happens if you write:

@@@ExampleAttribute()
class Foo
{
}

@@@some_function();

--
Aleksander Machniak
Kolab Groupware Developer        [https://kolab.org]
Roundcube Webmail Developer  [https://roundcube.net]
----------------------------------------------------
PGP: 19359DC1 # Blog: https://kolabian.wordpress.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Mark Randall

6 years ago

On 18/06/2020 00:59, Theodore Brown wrote:

> I've opened voting on the Shorter Attribute Syntax RFC:
> https://wiki.php.net/rfc/shorter_attribute_syntax

I'd be wary of @@ simply because if we do add validation to them, we
would likely want to use the suppression operator to indicate that a
class might be omitted (such as if an optional package is not installed).

At which point we're left with @@@ and that's getting into silly-land.

Mark Randall
marandall@php.net

Theodore Brown

6 years ago

On Wed, June 17, 2020 at 5:59 PM Theodore Brown wrote:

> I've opened voting on the Shorter Attribute Syntax RFC:
> https://wiki.php.net/rfc/shorter_attribute_syntax
> 
> Since all RFCs require a primary vote with a 2/3 majority, there is
> a main vote to approve the secondary ranked-choice vote.
> 
> For the ranked-choice poll, fill in your first through third syntax
> choices, making sure not to select the same syntax more than
> once. You don't have to vote for all three options, but please
> don't leave gaps.
> 
> Voting will end in two weeks, on 2020-07-01.

Hi internals,

The Shorter Attribute Syntax RFC vote is now closed. The primary poll
for re-voting on attribute syntax was approved with 50 in favor and 8
opposed.

For the secondary ranked-choice poll there are 61 valid ballots. Since
only one syntax can be elected, the quota is floor(61 / 2) + 1 = 31.

Note: one ballot wasn't counted since it selected the same syntax
more than once. However, this does not change the vote outcome.

In the first round the tally is as follows:

@@: 34 votes
#[]: 21 votes
<<>>: 6 votes

So @@ reaches the quota and has been elected as the final attribute
syntax for PHP 8.

Thank you to everyone who voted!

Theodore

Nikita Popov

6 years ago

On Thu, Jul 2, 2020 at 2:13 AM Theodore Brown <theodorejb@outlook.com>
wrote:

> On Wed, June 17, 2020 at 5:59 PM Theodore Brown wrote:
>
> > I've opened voting on the Shorter Attribute Syntax RFC:
> > https://wiki.php.net/rfc/shorter_attribute_syntax
> >
> > Since all RFCs require a primary vote with a 2/3 majority, there is
> > a main vote to approve the secondary ranked-choice vote.
> >
> > For the ranked-choice poll, fill in your first through third syntax
> > choices, making sure not to select the same syntax more than
> > once. You don't have to vote for all three options, but please
> > don't leave gaps.
> >
> > Voting will end in two weeks, on 2020-07-01.
>
> Hi internals,
>
> The Shorter Attribute Syntax RFC vote is now closed. The primary poll
> for re-voting on attribute syntax was approved with 50 in favor and 8
> opposed.
>
> For the secondary ranked-choice poll there are 61 valid ballots. Since
> only one syntax can be elected, the quota is floor(61 / 2) + 1 = 31.
>
> Note: one ballot wasn't counted since it selected the same syntax
> more than once. However, this does not change the vote outcome.
>
> In the first round the tally is as follows:
>
> @@: 34 votes
> #[]: 21 votes
> <<>>: 6 votes
>
> So @@ reaches the quota and has been elected as the final attribute
> syntax for PHP 8.
>
> Thank you to everyone who voted!
>

Hi Theodore,

Unfortunately, the RFC failed to mention a small, but important detail: The
@@ syntax is ambiguous, as pointed out by Martin Schröder:

function (@@X \ Y $param) { }

Taking into account that PHP allows whitespace between namespace
separators, this can either be interpreted as an attribute "X\Y" on an
untyped parameter, or as an attribute "X" on a "\Y" typed parameter.

The RFC implementation solves this by treating @@ and the following name as
a single token that does not permit whitespace. As such, it will be
interpreted as "X" with an "\Y" typed parameter.

Now, if this had been explicitly mentioned in the RFC, we could have made
an explicit decision to accept this language inconsistency: To forbid
whitespace in namespaced names for attributes only, unlike all other places
in PHP accepting namespaced names. However, it was not mentioned in the
RFC, and apart from the authors of the proposal, I don't think anyone was
aware of this ambiguity.

Fortunately, there is still a way to resolve this issue in a consistent
manner: Change the handling of namespaced names in PHP in general. This is
exactly what is proposed in
https://wiki.php.net/rfc/namespaced_names_as_token. If that proposal is
accepted, then the ambiguity would disappear (and the above example would
become a parse error).

My plan would be to change the
https://wiki.php.net/rfc/namespaced_names_as_token proposal to either only
deal with the handling of namespaced names (i.e. as a single,
whitespace-free token), or at least separate the other reserved keyword
related changes into a separate vote.

If that proposal passes, then there should be no issue with adopting the @@
syntax for attributes (unless there are other problems I'm not aware of?)
If it does not pass, then we'll have to discuss what we want to do here.

Regards,
Nikita

Theodore Brown

6 years ago

On Thu, July 2 2020 at 8:14 AM Nikita Popov <nikita.ppv@gmail.com> wrote:

> On Thu, Jul 2, 2020 at 2:13 AM Theodore Brown <theodorejb@outlook.com> wrote:
> > On Wed, June 17, 2020 at 5:59 PM Theodore Brown wrote:
> > 
> > > I've opened voting on the Shorter Attribute Syntax RFC:
> > > https://wiki.php.net/rfc/shorter_attribute_syntax
> > >
> > > Since all RFCs require a primary vote with a 2/3 majority, there is
> > > a main vote to approve the secondary ranked-choice vote.
> > >
> > > For the ranked-choice poll, fill in your first through third syntax
> > > choices, making sure not to select the same syntax more than
> > > once. You don't have to vote for all three options, but please
> > > don't leave gaps.
> > >
> > > Voting will end in two weeks, on 2020-07-01.
> > 
> > Hi internals,
> > 
> > The Shorter Attribute Syntax RFC vote is now closed. The primary poll
> > for re-voting on attribute syntax was approved with 50 in favor and 8
> > opposed.
> > 
> > For the secondary ranked-choice poll there are 61 valid ballots. Since
> > only one syntax can be elected, the quota is floor(61 / 2) + 1 = 31.
> > 
> > Note: one ballot wasn't counted since it selected the same syntax
> > more than once. However, this does not change the vote outcome.
> > 
> > In the first round the tally is as follows:
> > 
> > @@: 34 votes  
> > #[]: 21 votes  
> > <<>>: 6 votes  
> > 
> > So @@ reaches the quota and has been elected as the final attribute
> > syntax for PHP 8.
> > 
> > Thank you to everyone who voted!
>
>
> Hi Theodore,
> 
> Unfortunately, the RFC failed to mention a small, but important detail:
> The @@ syntax is ambiguous, as pointed out by Martin Schröder:
>
> function (@@X \ Y $param) { }
> 
> Taking into account that PHP allows whitespace between namespace
> separators, this can either be interpreted as an attribute "X\Y" on an
> untyped parameter, or as an attribute "X" on a "\Y" typed parameter.
> 
> The RFC implementation solves this by treating @@ and the following name
> as a single token that does not permit whitespace. As such, it will be
> interpreted as "X" with an "\Y" typed parameter.
> 
> Now, if this had been explicitly mentioned in the RFC, we could have made
> an explicit decision to accept this language inconsistency: To forbid
> whitespace in namespaced names for attributes only, unlike all other
> places in PHP accepting namespaced names. However, it was not mentioned
> in the RFC, and apart from the authors of the proposal, I don't think
> anyone was aware of this ambiguity.
>
> Fortunately, there is still a way to resolve this issue in a consistent
> manner: Change the handling of namespaced names in PHP in general. This
> is exactly what is proposed in https://wiki.php.net/rfc/namespaced_names_as_token.
> If that proposal is accepted, then the ambiguity would disappear (and
> the above example would become a parse error).
> 
> My plan would be to change the https://wiki.php.net/rfc/namespaced_names_as_token
> proposal to either only deal with the handling of namespaced names
> (i.e. as a single, whitespace-free token), or at least separate the
> other reserved keyword related changes into a separate vote.
> 
> If that proposal passes, then there should be no issue with adopting the
> @@ syntax for attributes (unless there are other problems I'm not aware
> of?) If it does not pass, then we'll have to discuss what we want to do
> here.

Hi Nikita,

Thanks for bringing this up. The original Attributes v2 RFC mentioned
that the shorter @: syntax "does not permit whitespace in attribute
names to allow detecting the ending of the declaration", but when I
wrote the new RFC I didn't think to mention that this applies to @@
as well (the implementation is almost exactly the same).

It certainly could be considered inconsistent that whitespace is
allowed in most namespaced names, but not attributes. On the other
hand, since attributes are new syntax anyway it's arguably okay for
them to have stricter semantics.

But I agree that the ideal solution would be to change the handling of
namespaced names in general, per your https://wiki.php.net/rfc/namespaced_names_as_token
RFC. This would also have the benefit of minimizing the impact of
reserving new keywords.

Best regards,
Theodore