[RFC] Treat namespaced names as single token, relax reserved keyword restrictions

Sebastian Bergmann

6 years ago

Am 16.06.2020 um 10:52 schrieb Nikita Popov:

> https://wiki.php.net/rfc/namespaced_names_as_token

+1

> The RFC comes with a small backwards compatibility break related to names
> that include whitespace, but will hopefully reduce the backwards
> compatibility impact of future reserved keyword additions.

This statement misses the fact that code which uses token_get_all() needs
to be updated due to the new T_NAME_* tokens. The RFC itself lists this
change, so that's okay.

Davey

6 years ago

On Tue, Jun 16, 2020 at 1:52 AM Nikita Popov <nikita.ppv@gmail.com> wrote:

> Hi internals,
>
> Inspired by the recent discussion on reserved keyword reservation, I'd like
> to propose the following RFC:
>
> https://wiki.php.net/rfc/namespaced_names_as_token
>
> This RFC makes two related changes: Treat namespaced names as a single
> token, which enables use of reserved keywords inside them. And remove
> reserved keyword restrictions from various declarations.
>
> The RFC comes with a small backwards compatibility break related to names
> that include whitespace, but will hopefully reduce the backwards
> compatibility impact of future reserved keyword additions.
>
> Regards,
> Nikita
>

The only issue I have with this RFC is this:

use Foo as KEYWORD;

While this might be _technically_ correct, it is unusable. That is:

use Foo as List;

class Bar extends List { } // this will not work

Given this, I think this specific syntax should be an error, unless I'm
missing something?

Also, does this mean we can alias to fully namespaced names now?

use \My\Foo as \Bar\Foo;
class Bat extends \Bar\Foo { } // now actually extends \My\Foo, not
\Bar\Foo (no autoload would happen?)

- Davey

Nikita Popov

6 years ago

On Tue, Jun 16, 2020 at 10:28 PM Davey Shafik <davey@php.net> wrote:

>
>
> On Tue, Jun 16, 2020 at 1:52 AM Nikita Popov <nikita.ppv@gmail.com> wrote:
>
>> Hi internals,
>>
>> Inspired by the recent discussion on reserved keyword reservation, I'd
>> like
>> to propose the following RFC:
>>
>> https://wiki.php.net/rfc/namespaced_names_as_token
>>
>> This RFC makes two related changes: Treat namespaced names as a single
>> token, which enables use of reserved keywords inside them. And remove
>> reserved keyword restrictions from various declarations.
>>
>> The RFC comes with a small backwards compatibility break related to names
>> that include whitespace, but will hopefully reduce the backwards
>> compatibility impact of future reserved keyword additions.
>>
>> Regards,
>> Nikita
>>
>
> The only issue I have with this RFC is this:
>
> use Foo as KEYWORD;
>
> While this might be _technically_ correct, it is unusable. That is:
>
> use Foo as List;
>
> class Bar extends List { } // this will not work
>

That's correct. However, "class Bar extends List\FooBar" will work.

I mainly allow this because "use Foo\Bar" is the same as "use Foo\Bar as
Bar". If "use Foo\List" is allowed, it makes little sense to forbid the
equivalent "use Foo\List as List".

Given this, I think this specific syntax should be an error, unless I'm

> missing something?
>
> Also, does this mean we can alias to fully namespaced names now?
>
> use \My\Foo as \Bar\Foo;
> class Bat extends \Bar\Foo { } // now actually extends \My\Foo, not
> \Bar\Foo (no autoload would happen?)
>

No, this continues to be not allowed. "As" does not accept a namespaced
name, it accepts a single identifier.

Regards,
Nikita

Davey

6 years ago

On Tue, Jun 16, 2020 at 1:34 PM Nikita Popov <nikita.ppv@gmail.com> wrote:

> On Tue, Jun 16, 2020 at 10:28 PM Davey Shafik <davey@php.net> wrote:
>
>>
>>
>> On Tue, Jun 16, 2020 at 1:52 AM Nikita Popov <nikita.ppv@gmail.com>
>> wrote:
>>
>>> Hi internals,
>>>
>>> Inspired by the recent discussion on reserved keyword reservation, I'd
>>> like
>>> to propose the following RFC:
>>>
>>> https://wiki.php.net/rfc/namespaced_names_as_token
>>>
>>> This RFC makes two related changes: Treat namespaced names as a single
>>> token, which enables use of reserved keywords inside them. And remove
>>> reserved keyword restrictions from various declarations.
>>>
>>> The RFC comes with a small backwards compatibility break related to names
>>> that include whitespace, but will hopefully reduce the backwards
>>> compatibility impact of future reserved keyword additions.
>>>
>>> Regards,
>>> Nikita
>>>
>>
>> The only issue I have with this RFC is this:
>>
>> use Foo as KEYWORD;
>>
>> While this might be _technically_ correct, it is unusable. That is:
>>
>> use Foo as List;
>>
>> class Bar extends List { } // this will not work
>>
>
> That's correct. However, "class Bar extends List\FooBar" will work.
>

Hadn't considered this! Good point.

>
> I mainly allow this because "use Foo\Bar" is the same as "use Foo\Bar as
> Bar". If "use Foo\List" is allowed, it makes little sense to forbid the
> equivalent "use Foo\List as List".
>
> Given this, I think this specific syntax should be an error, unless I'm
>> missing something?
>>
>

Looks like I was, consider my concern assuaged :)

>
>> Also, does this mean we can alias to fully namespaced names now?
>>
>> use \My\Foo as \Bar\Foo;
>> class Bat extends \Bar\Foo { } // now actually extends \My\Foo, not
>> \Bar\Foo (no autoload would happen?)
>>
>
> No, this continues to be not allowed. "As" does not accept a namespaced
> name, it accepts a single identifier.
>

But now the namespace _is_ a single identifier. Or at least, it creates
some (minimal) confusion here IMO.

- Davey

Jakob Givoni

6 years ago

On Tue, Jun 16, 2020 at 10:52 AM Nikita Popov <nikita.ppv@gmail.com> wrote:

>
> Hi internals,
>
> Inspired by the recent discussion on reserved keyword reservation, I'd like
> to propose the following RFC:
>
> https://wiki.php.net/rfc/namespaced_names_as_token
>
> This RFC makes two related changes: Treat namespaced names as a single
> token, which enables use of reserved keywords inside them. And remove
> reserved keyword restrictions from various declarations.
>
> The RFC comes with a small backwards compatibility break related to names
> that include whitespace, but will hopefully reduce the backwards
> compatibility impact of future reserved keyword additions.
>
> Regards,
> Nikita

Love it, thanks Nikita!

In a mail that probably went to everyone's spam folder, I asked for
opinions on allowing use of .\Foo as an alternative to Foo in the
current namespace, thus reducing friction with reserved keywords even
more. Any thoughts on that now?

Best,
Jakob

Nikita Popov

6 years ago

On Thu, Jun 18, 2020 at 12:06 AM Jakob Givoni <jakob@givoni.dk> wrote:

> On Tue, Jun 16, 2020 at 10:52 AM Nikita Popov <nikita.ppv@gmail.com>
> wrote:
> >
> > Hi internals,
> >
> > Inspired by the recent discussion on reserved keyword reservation, I'd
> like
> > to propose the following RFC:
> >
> > https://wiki.php.net/rfc/namespaced_names_as_token
> >
> > This RFC makes two related changes: Treat namespaced names as a single
> > token, which enables use of reserved keywords inside them. And remove
> > reserved keyword restrictions from various declarations.
> >
> > The RFC comes with a small backwards compatibility break related to names
> > that include whitespace, but will hopefully reduce the backwards
> > compatibility impact of future reserved keyword additions.
> >
> > Regards,
> > Nikita
>
> Love it, thanks Nikita!
>
> In a mail that probably went to everyone's spam folder, I asked for
> opinions on allowing use of .\Foo as an alternative to Foo in the
> current namespace, thus reducing friction with reserved keywords even
> more. Any thoughts on that now?
>

How would .\Foo be different from the currently existing namespace\Foo?
(Note that "namespace" here is to be taken literally, not as "put the
current namespace here").

Nikita

Jakob Givoni

6 years ago

On Thu, Jun 18, 2020 at 9:39 AM Nikita Popov <nikita.ppv@gmail.com> wrote:

>
>> In a mail that probably went to everyone's spam folder, I asked for
>> opinions on allowing use of .\Foo as an alternative to Foo in the
>> current namespace, thus reducing friction with reserved keywords even
>> more. Any thoughts on that now?
>
>
> How would .\Foo be different from the currently existing namespace\Foo? (Note that "namespace" here is to be taken literally, not as "put the current namespace here").
>

I didn't know you could do that! I don't think I've ever seen it used,
maybe because there's been little advantage over just Foo? I guess it
only matters if you also import Foo?
For what it's worth, .\Foo would be significantly shorter than
namespace\Foo and probably more intuitive to understand as well.
Furthermore, if you were to create a namespace called "Namespace"
(don't judge! ;-)), which I would assume would be possible should this
RFC be implemented, we could avoid namespace\Namespace\Foo :-D

Thanks for the feedback, it was just an idea - could be a new RFC some
other day.

Thanks,
Jakob

Michael Morris

6 years ago

What other language allows this? None that I can think of. Do we want PHP
doing something it's most closely related languages do not allow?  Why
don't they allow this? What problems are we creating by allowing this? I
can imagine this would make autoloading functions and constants by
namespace more complicated, but I'm not sure.

On Tue, Jun 16, 2020 at 3:52 AM Nikita Popov <nikita.ppv@gmail.com> wrote:

Marcio Almada

6 years ago

Hi,

What other language allows this? None that I can think of. Do we want PHP

> doing something it's most closely related languages do not allow?  Why
> don't they allow this?

Most language implementations don't do that because we are all using
parser generators to do the heavy lifting of parsing and these often force
us to pretend our programming languages are context free, and we accept
that for convenience. But most of the programming languages - C, C++,
Python, Ruby, JS, PHP, SQL - are not really context-free.

> What problems are we creating by allowing this?

In that case, this RFC makes it unnecessary to soft reserve words like
`enum`
to avoid BC breaks during PHP8 lifetime.

> I can imagine this would make autoloading functions and constants by
> namespace more complicated, but I'm not sure.

I don't see how this would be harder with this proposal being accepted.

Ty,
Márcio Almada

Claude Pache

6 years ago

Hi,

The following part of the proposal is problematic: Allow keywords in definition of classes, functions, const, etc.

class KEYWORD {}
interface KEYWORD {}
trait KEYWORD {}
function KEYWORD() {}
const KEYWORD = 0;
use Foo as KEYWORD;
Under your proposal, the following code will compile without notice, but will have a different behaviour from what the programmer intended:

```php
class Int { }

const PRINT = 2;
const YIELD = 3;

function foo(Int $b) {
return PRINT + YIELD;
}
```

If it is important to allow to define classes, etc. with a keyword as name, I suggest to force the programmer to say explicitly “Yes, it is really what I want”. For example, something like the following:

```php
class namespace\Int { }

const namespace\PRINT = 2;
```

Another point which is problematic, is to allow `namespace` as a namespace parts, since `namespace\foo`, although interpreted as a namespace-relative name, could be intended to be a qualified name by the programmer.

—Claude

Nikita Popov

6 years ago

On Thu, Jun 18, 2020 at 8:44 AM Claude Pache <claude.pache@gmail.com> wrote:

> Hi,
>
> The following part of the proposal is problematic: Allow keywords in
> definition of classes, functions, const, etc.
>
> class KEYWORD {}interface KEYWORD {}trait KEYWORD {}function KEYWORD() {}const KEYWORD = 0;use Foo as KEYWORD;
>
> Under your proposal, the following code will compile without notice, but
> will have a different behaviour from what the programmer intended:
>
> ```php
> class Int { }
>

This part will still produce an error: "int" is not a reserved keyword, but
it is a reserved class name, and handled by a different mechanism.

const PRINT = 2;

> const YIELD = 3;
>
> function foo(Int $b) {
>     return PRINT + YIELD;
> }
> ```
>

Yes, this is the tradeoff :) We trade the ability to use reserved keywords
in controlled situations, with potential confusion for cases like these.

If it is important to allow to define classes, etc. with a keyword as name,

> I suggest to force the programmer to say explicitly “Yes, it is really what
> I want”. For example, something like the following:
>
> ```php
> class namespace\Int { }
>
> const namespace\PRINT = 2;
> ```
>

This syntax doesn't make much sense to me. If we go down that line, I'd
suggest something along the lines of Rust's "raw identifier" concept, which
would allow you to write "const r#PRINT = 2" and "echo r#PRINT". This
syntax would work everywhere identifiers are accepted, e.g. the "namespace
iter\fn" would become "namespace iter\r#fn".

The disadvantage of this approach is that it is not backwards compatible
with PHP 7 and requires more active code change. E.g. the iter\fn example
would "just work" under this RFC, while this approach would require
rewriting the code.

Nikita

Another point which is problematic, is to allow `namespace` as a namespace

Claude Pache

6 years ago

> Le 16 juin 2020 à 10:52, Nikita Popov <nikita.ppv@gmail.com> a écrit :
>
> Hi internals,
>
> Inspired by the recent discussion on reserved keyword reservation, I'd like
> to propose the following RFC:
>
> https://wiki.php.net/rfc/namespaced_names_as_token
>
> This RFC makes two related changes: Treat namespaced names as a single
> token, which enables use of reserved keywords inside them. And remove
> reserved keyword restrictions from various declarations.
>
> The RFC comes with a small backwards compatibility break related to names
> that include whitespace, but will hopefully reduce the backwards
> compatibility impact of future reserved keyword additions.
>
> Regards,
> Nikita

In fact, for classes and namespaces, we can probably do better, namely we can lift almost all keyword restriction, not only in definition and declaration, but also in in use.

Indeed, bare names of class (and trait, interface, etc) and namespace can appear only in few, well-defined positions, where it cannot be confused with a keyword, namely:

* after a handful of keywords: `new yield`, `class yield`, `instanceof yield`, `use yield`, `use foo as yield`, etc.
* before a paamayim nekudotayim: `yield::$foo`, `yield::foo()`, `yield::FOO`;
* before a backslash: `yield\foo`.

As far as I can see, the only keywords that can legally appear in those positions (and therefore must remain unavailable) are: `namespace` (because of namespace-relative names: `namespace\foo`), and `class` (because of anonymous classes: `new class { }`.

(As for functions and constants, I’m still thinking that it is not a good idea to allow to define or import a symbol that cannot be used. You will make the life of few library maintainers a little easier, but you will make the life of many users a little harder.)

—Claude

Nikita Popov

6 years ago

On Tue, Jun 16, 2020 at 10:52 AM Nikita Popov <nikita.ppv@gmail.com> wrote:

> Hi internals,
>
> Inspired by the recent discussion on reserved keyword reservation, I'd
> like to propose the following RFC:
>
> https://wiki.php.net/rfc/namespaced_names_as_token
>
> This RFC makes two related changes: Treat namespaced names as a single
> token, which enables use of reserved keywords inside them. And remove
> reserved keyword restrictions from various declarations.
>
> The RFC comes with a small backwards compatibility break related to names
> that include whitespace, but will hopefully reduce the backwards
> compatibility impact of future reserved keyword additions.
>

I have reduced the scope of this RFC to handle just the issue of namespaced
names, without touching any other reserved keyword restrictions. As the
discussion shows, those are trickier, with more cases of perceived
ambiguity that may need to be mitigated.

As this proposal is now a prerequisite for
https://wiki.php.net/rfc/shorter_attribute_syntax, I have heard from a
disturbing number of people that they might vote against this proposal, not
because they disagree with it, but because that would prevent the adoption
of the @@ attribute syntax. I'm not sure what to do about that...

Regards,
Nikita

Nikita Popov

6 years ago

On Thu, Jul 9, 2020 at 4:33 PM Nikita Popov <nikita.ppv@gmail.com> wrote:

> On Tue, Jun 16, 2020 at 10:52 AM Nikita Popov <nikita.ppv@gmail.com>
> wrote:
>
>> Hi internals,
>>
>> Inspired by the recent discussion on reserved keyword reservation, I'd
>> like to propose the following RFC:
>>
>> https://wiki.php.net/rfc/namespaced_names_as_token
>>
>> This RFC makes two related changes: Treat namespaced names as a single
>> token, which enables use of reserved keywords inside them. And remove
>> reserved keyword restrictions from various declarations.
>>
>> The RFC comes with a small backwards compatibility break related to names
>> that include whitespace, but will hopefully reduce the backwards
>> compatibility impact of future reserved keyword additions.
>>
>
> I have reduced the scope of this RFC to handle just the issue of
> namespaced names, without touching any other reserved keyword restrictions.
> As the discussion shows, those are trickier, with more cases of perceived
> ambiguity that may need to be mitigated.
>
> As this proposal is now a prerequisite for
> https://wiki.php.net/rfc/shorter_attribute_syntax, I have heard from a
> disturbing number of people that they might vote against this proposal, not
> because they disagree with it, but because that would prevent the adoption
> of the @@ attribute syntax. I'm not sure what to do about that...
>

Heads up: I plan to open voting on this proposal tomorrow, unless there is
further feedback.

Nikita

Brent

6 years ago

Hi Nikita

What happens to the attributes syntax if this RFC doesn't pass?

Furthermore, I think voting against this RFC to prevent the @@ syntax from happening is an abuse of the system. If there are problems with the attribute syntax, than the vote results on that one should be called void and a revote should happen, but it shouldn't affect the vote of this RFC, which has a larger impact than just the attributes syntax.

Kind regards
Brent

Josh Bruce

6 years ago

New to the discussion and being this deep; so, apologies for any bumps. Mainly questions.

Does this only affect the string after the “namespace” keyword (make implicit explicit)?

So, things like “use” with a stack of classes within a base namespace would still be possible? On reserved words, if I had class “String” would that still throw a reserved word violation?

Cheers,
Josh

Nikita Popov

6 years ago

On Tue, Jul 14, 2020 at 5:37 PM Josh Bruce <josh@joshbruce.dev> wrote:

> New to the discussion and being this deep; so, apologies for any bumps.
> Mainly questions.
>
> Does this only affect the string after the “namespace” keyword (make
> implicit explicit)?
>

This affects any place accepting namespaced names. The only part that is
specific to the "namespace" keyword is that you can write "namespace
reserved_keyword;", which would not automatically be the case based on the
rest of the proposal.

So, things like “use” with a stack of classes within a base namespace would

> still be possible?

You mean the group use syntax "use Foo\Bar\{A, B};"? That's still possible.
In this case we'd interpret Foo\Bar" as a namespaced name and "\" as an
isolated namespace separator. This is the only case where "\" is still used
as an independent symbol.

> On reserved words, if I had class “String” would that still throw a
> reserved word violation?
>

Yes, nothing about handling of reserved class names is changing under the
current proposal.

Nikita

Josh Bruce

6 years ago

> On Jul 15, 2020, at 3:26 AM, Nikita Popov <nikita.ppv@gmail.com> wrote:
>
> On Tue, Jul 14, 2020 at 5:37 PM Josh Bruce <josh@joshbruce.dev <mailto:josh@joshbruce.dev>> wrote:
> New to the discussion and being this deep; so, apologies for any bumps. Mainly questions.
>
> Does this only affect the string after the “namespace” keyword (make implicit explicit)?
>
> This affects any place accepting namespaced names. The only part that is specific to the "namespace" keyword is that you can write "namespace reserved_keyword;", which would not automatically be the case based on the rest of the proposal.
>
> So, things like “use” with a stack of classes within a base namespace would still be possible?
>
> You mean the group use syntax "use Foo\Bar\{A, B};"? That's still possible. In this case we'd interpret Foo\Bar" as a namespaced name and "\" as an isolated namespace separator. This is the only case where "\" is still used as an independent symbol.
>
> On reserved words, if I had class “String” would that still throw a reserved word violation?
>
> Yes, nothing about handling of reserved class names is changing under the current proposal.
>
> Nikita

Got it. Thanks Nikita!

Much appreciated and could have a fair amount of benefit on both sides of the equation (dev and PHP).

Cheers,
Josh

tyson andre

6 years ago

Nikita Popov

6 years ago

On Thu, Jul 16, 2020 at 3:40 AM tyson andre <tysonandre775@hotmail.com>
wrote:

> > > I have reduced the scope of this RFC to handle just the issue of
> > > namespaced names, without touching any other reserved keyword
> restrictions.
> > > As the discussion shows, those are trickier, with more cases of
> perceived
> > > ambiguity that may need to be mitigated.
> > >
> > > As this proposal is now a prerequisite for
> > > https://wiki.php.net/rfc/shorter_attribute_syntax, I have heard from a
> > > disturbing number of people that they might vote against this
> proposal, not
> > > because they disagree with it, but because that would prevent the
> adoption
> > > of the @@ attribute syntax. I'm not sure what to do about that...
> > >
> >
> > Heads up: I plan to open voting on this proposal tomorrow, unless there
> is
> > further feedback.
>
> One possibility would be to split it up into two separate RFCs:
> (This would probably be too short notice, and this isn't similar to any
> proposal in the past)
>
> 1. An Yes/No RFC requiring a 2/3 majority for accepting the amended `@@`
> attribute syntax with the restriction the original RFC proposed (no
> whitespace&reserved words.
>
>    I'd think that very few proponents of `@@` had plans to mix whitespace
> with backslashes in attributes when reading that RFC, and it's extremely
> similar to the original attribute syntax change RFC.
>

While I don't think anyone had plans to mix whitespace, this is indicative
of a larger issue. While I'm one of the people who voted for @@ as my first
choice before, I wouldn't do so now (even with this RFC accepted). This
issue made me realize that there is more at stake here than just "which
syntax is prettier?" and choices that have a "closing tag" are technically
more favorable, especially if we consider future extensions of the
attribute system that may introduce additional ambiguities (e.g., Rust
allows placing attributes pretty much everywhere in code -- how sure are we
that there will be no unanticipated ambiguities?)

Probably the most unambiguous treatment here would be to simply rerun the
vote on the short attribute syntax after this RFC is decided one way or
another, but that would be quite a bit of process overhead, for what is a
small issue to most people.

> 2. A yes/no RFC for this RFC to affect everything except the choice of
> attribute syntax.
>    (i.e. if 2 passes but not 1, we'd end up using `<<Attribute\Name>>` in
> 8.0 and forbidding `<<Attribute \ Name>>`)
>

Just to be clear, the whitespace issue affects only the @@ syntax, not the
<<>> or #[] syntaxes.

Nikita

Still, my proposal seems like a dissatisfying one.

Peter Bowyer

6 years ago

On Thu, 16 Jul 2020 at 09:04, Nikita Popov <nikita.ppv@gmail.com> wrote:

> While I don't think anyone had plans to mix whitespace, this is indicative
> of a larger issue. While I'm one of the people who voted for @@ as my first
> choice before, I wouldn't do so now (even with this RFC accepted). This
> issue made me realize that there is more at stake here than just "which
> syntax is prettier?" and choices that have a "closing tag" are technically
> more favorable, especially if we consider future extensions of the
> attribute system that may introduce additional ambiguities (e.g., Rust
> allows placing attributes pretty much everywhere in code -- how sure are we
> that there will be no unanticipated ambiguities?)
>

Thanks for this clear explainer. I hadn't appreciated the "no closing
delimiter" issues during the original vote, also picking @@.

As many other languages use '@' as their symbol, how do they handle or
avoid the whitespace issues?

Peter

Nicolas Grekas

6 years ago

> > > > I have reduced the scope of this RFC to handle just the issue of
> > > > namespaced names, without touching any other reserved keyword
> > restrictions.
> > > > As the discussion shows, those are trickier, with more cases of
> > perceived
> > > > ambiguity that may need to be mitigated.
> > > >
> > > > As this proposal is now a prerequisite for
> > > > https://wiki.php.net/rfc/shorter_attribute_syntax, I have heard
> from a
> > > > disturbing number of people that they might vote against this
> > proposal, not
> > > > because they disagree with it, but because that would prevent the
> > adoption
> > > > of the @@ attribute syntax. I'm not sure what to do about that...
> > > >
> > >
> > > Heads up: I plan to open voting on this proposal tomorrow, unless there
> > is
> > > further feedback.
> >
> > One possibility would be to split it up into two separate RFCs:
> > (This would probably be too short notice, and this isn't similar to any
> > proposal in the past)
> >
> > 1. An Yes/No RFC requiring a 2/3 majority for accepting the amended `@@`
> > attribute syntax with the restriction the original RFC proposed (no
> > whitespace&reserved words.
> >
> >    I'd think that very few proponents of `@@` had plans to mix whitespace
> > with backslashes in attributes when reading that RFC, and it's extremely
> > similar to the original attribute syntax change RFC.
> >
>
> While I don't think anyone had plans to mix whitespace, this is indicative
> of a larger issue. While I'm one of the people who voted for @@ as my first
> choice before, I wouldn't do so now (even with this RFC accepted). This
> issue made me realize that there is more at stake here than just "which
> syntax is prettier?" and choices that have a "closing tag" are technically
> more favorable, especially if we consider future extensions of the
> attribute system that may introduce additional ambiguities (e.g., Rust
> allows placing attributes pretty much everywhere in code -- how sure are we
> that there will be no unanticipated ambiguities?)
>
> Probably the most unambiguous treatment here would be to simply rerun the
> vote on the short attribute syntax after this RFC is decided one way or
> another, but that would be quite a bit of process overhead, for what is a
> small issue to most people.
>
>
> > 2. A yes/no RFC for this RFC to affect everything except the choice of
> > attribute syntax.
> >    (i.e. if 2 passes but not 1, we'd end up using `<<Attribute\Name>>` in
> > 8.0 and forbidding `<<Attribute \ Name>>`)
> >
>
> Just to be clear, the whitespace issue affects only the @@ syntax, not the
> <<>> or #[] syntaxes.
>

It is my understanding that implementation concerns are a valid reason to
invalidate a vote, especially when they are found after the vote happened.

If we really want to keep the @@ syntax, there might still be a way: the
syntax could require using brackets after the attribute name:

@@Foo => @@Foo()

But I voted for #[Foo] so I'm not preaching my own preference by making
this suggestion ;)

Nicolas

Theodore Brown

6 years ago

On Thu, July 16 2020 at 3:04 AM Nikita Popov <nikita.ppv@gmail.com> wrote:

> While I don't think anyone had plans to mix whitespace, this is
> indicative of a larger issue. While I'm one of the people who voted
> for @@ as my first choice before, I wouldn't do so now (even with
> this RFC accepted). This issue made me realize that there is more at
> stake here than just "which syntax is prettier?" and choices that
> have a "closing tag" are technically more favorable, especially if
> we consider future extensions of the attribute system that may
> introduce additional ambiguities (e.g., Rust allows placing
> attributes pretty much everywhere in code -- how sure are we that
> there will be no unanticipated ambiguities?)

Hi Nikita,

Can you think of an example that would cause an ambiguity even when
namespaced names are treated as tokens? As I understand it, there
can't be an ambiguity, since there would always be an attribute token
followed by a class name token. It should be possible to put this
anywhere it makes sense without ambiguities.

Other languages like Java allow attributes/annotations in more places
than PHP (e.g. on variables) and the @ syntax doesn't prevent this.

Theodore

Nikita Popov

6 years ago

On Thu, Jul 16, 2020 at 3:00 PM Theodore Brown <theodorejb@outlook.com>
wrote:

> On Thu, July 16 2020 at 3:04 AM Nikita Popov <nikita.ppv@gmail.com> wrote:
>
> > While I don't think anyone had plans to mix whitespace, this is
> > indicative of a larger issue. While I'm one of the people who voted
> > for @@ as my first choice before, I wouldn't do so now (even with
> > this RFC accepted). This issue made me realize that there is more at
> > stake here than just "which syntax is prettier?" and choices that
> > have a "closing tag" are technically more favorable, especially if
> > we consider future extensions of the attribute system that may
> > introduce additional ambiguities (e.g., Rust allows placing
> > attributes pretty much everywhere in code -- how sure are we that
> > there will be no unanticipated ambiguities?)
>
> Hi Nikita,
>
> Can you think of an example that would cause an ambiguity even when
> namespaced names are treated as tokens? As I understand it, there
> can't be an ambiguity, since there would always be an attribute token
> followed by a class name token. It should be possible to put this
> anywhere it makes sense without ambiguities.
>

Yes, there should not be any ambiguities at present. This is more of a
vague unease when it comes to future language extensions. To give an
example: Let's say that in the future, we allow annotations on statements,
and introduce generics using the ClassName{T} syntax (it's unlikely we'd
actually do that, even though this is the "least ambiguous" generics
syntax). Now, if attributes are just classes, it would stand to reason that
you can use something like @@OfType{int} as an attribute. If we combine
these two language changes, we get

@@FooBar
{
SomethingComplexHere
}

where SomethignComplexHere could be interpreted both as a type or an
expression. This does not cause a "true" ambiguity, but it does add an
infinite lookahead parser requirement, because we will only know how to
interpret this at the }. It could be an attribute with a generic parameter,
or it could be a non-generic attribute on a code block.

Of course, it is more likely than not, that we will not encounter any
issues of that nature.

Nikita