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

3 years ago by Sebastian Bergmann — view source

unread

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.

3 years ago by Davey Shafik — view source

unread

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

3 years ago by Nikita Popov — view source

unread

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

3 years ago by Davey Shafik — view source

unread

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

3 years ago by Jakob Givoni — view source

unread

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

3 years ago by Nikita Popov — view source

unread

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

3 years ago by Jakob Givoni — view source

unread

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

3 years ago by Michael Morris — view source

unread

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.

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

3 years ago by Marcio Almada — view source

unread

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

3 years ago by Claude Pache — view source

unread

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:

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:

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

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

3 years ago by Nikita Popov — view source

unread

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:
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:
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

parts, since namespace\foo, although interpreted as a namespace-relative
name, could be intended to be a qualified name by the programmer.

—Claude

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

3 years ago by Claude Pache — view source

unread

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

3 years ago by Nikita Popov — view source

unread

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

3 years ago by Nikita Popov — view source

unread

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

3 years ago by Brent Roose — view source

unread

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

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

3 years ago by tyson andre — view source

unread

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)

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.
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>>)

Still, my proposal seems like a dissatisfying one.

Allowing future 3+-way votes to be re-voted once due to unexpected implementation concerns
(when the original authors are among the authors of the amendment)
with a 50% majority requirement (instead of 2/3) might help in the future,
but would probably entail its own process vote for an extremely rare/narrow RFC situation.
That wouldn't help with this RFC due to the feature freeze,
and I think that situation's too rare to actually work out details and actually propose that amendment.

P.S. I'm in favor of removing whitespace between tokens of names.

Tyson

3 years ago by Nikita Popov — view source

unread

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)

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.

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.

Allowing future 3+-way votes to be re-voted once due to unexpected
implementation concerns
(when the original authors are among the authors of the amendment)
with a 50% majority requirement (instead of 2/3) might help in the future,
but would probably entail its own process vote for an extremely
rare/narrow RFC situation.
That wouldn't help with this RFC due to the feature freeze,
and I think that situation's too rare to actually work out details and
actually propose that amendment.

P.S. I'm in favor of removing whitespace between tokens of names.

Tyson

3 years ago by Peter Bowyer — view source

unread

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

3 years ago by Nicolas Grekas — view source

unread

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)

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.

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

3 years ago by Theodore Brown — view source

unread

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

3 years ago by Nikita Popov — view source

unread

On Thu, Jul 16, 2020 at 3:00 PM Theodore Brown theodorejb@outlook.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