Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110648
MIME-Version: 1.0
References: <CAF+90c9ow-_=DSZ9LFhKzA1ZgHcf0LPt-p7tnhKRcgVUBnLfZw@mail.gmail.com>
 <870E22A7-879D-415C-B7D0-71560B9CE156@gmail.com>
In-Reply-To: <870E22A7-879D-415C-B7D0-71560B9CE156@gmail.com>
Date: Thu, 18 Jun 2020 09:46:56 +0200
Message-ID: <CAF+90c-Bjh2TXgPjBhU1xkC=AGwtJ_JKbpryoVa2nDztxv1=QQ@mail.gmail.com>
To: Claude Pache <claude.pache@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000ff931805a856fba9"
Subject: Re: [PHP-DEV] [RFC] Treat namespaced names as single token, relax
 reserved keyword restrictions
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000ff931805a856fba9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 =3D 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 =3D 2;
> const YIELD =3D 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 =E2=80=9CYes, it is r=
eally what
> I want=E2=80=9D. For example, something like the following:
>
> ```php
> class namespace\Int { }
>
> const namespace\PRINT =3D 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 =3D 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-relativ=
e
> name, could be intended to be a qualified name by the programmer.
>
> =E2=80=94Claude
>
>
>
>
> Le 16 juin 2020 =C3=A0 10:52, Nikita Popov <nikita.ppv@gmail.com> a =C3=
=A9crit :
>
> Hi internals,
>
> Inspired by the recent discussion on reserved keyword reservation, I'd li=
ke
> 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
>
>
>

--000000000000ff931805a856fba9--