Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110973
MIME-Version: 1.0
References: <CABdc3WoOjDqoGxC+Z15F5kvcU=8NZvOGUCx5XwG6DgM+_H_r2A@mail.gmail.com>
 <CAF+90c_p7gjMvgsts7brP2nxNHMAWCxhn9mqE_VgmOQAYOYkiA@mail.gmail.com> <CABdc3Wp+V27Stzx3DBBKLNLAnCMepOWybEsQ2_TakZyiMkSc8Q@mail.gmail.com>
In-Reply-To: <CABdc3Wp+V27Stzx3DBBKLNLAnCMepOWybEsQ2_TakZyiMkSc8Q@mail.gmail.com>
Date: Mon, 13 Jul 2020 14:33:41 +0300
Message-ID: <CANeKSiT3sGHhK0r5GadzNMbE+st+dcLr4QkWviiijhhbFwsN1w@mail.gmail.com>
To: =?UTF-8?Q?Micha=C5=82_Marcin_Brzuchalski?= <michal.brzuchalski@gmail.com>
Cc: Nikita Popov <nikita.ppv@gmail.com>, PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000cd02c605aa5110e0"
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Language Constructs Syntax Changes
From: benas.molis.iml@gmail.com (Benas IML)

--000000000000cd02c605aa5110e0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hey Micha=C5=82,

Personally, I think instead of making `declare(strict_types=3D1);` to look
more like a constant, we should make it look more like a function.

Since it seems that the named parameters RFC is going to be accepted, I
think allowing for alternative `declare(strict_types: 1);` syntax would
make much more sense.

Best regards,
Benas


On Mon, Jul 13, 2020, 2:08 PM Micha=C5=82 Marcin Brzuchalski <
michal.brzuchalski@gmail.com> wrote:

> Hi Nikita,
>
> pon., 13 lip 2020 o 12:41 Nikita Popov <nikita.ppv@gmail.com> napisa=C5=
=82(a):
>
> > On Sun, Jul 5, 2020 at 9:36 AM Micha=C5=82 Marcin Brzuchalski <
> > michal.brzuchalski@gmail.com> wrote:
> >
> >> Hi internals,
> >>
> >> I realise we're tight to the deadline but from my calculations,
> >> this RFC should fit with 2w discussion and 2w voting before feature
> >> freeze.
> >>
> >> The proposal is to allow two statements to skip parentheses so they
> don't
> >> look like expressions.
> >> This goes to `declare` and `__halt_compiler`.
> >> Changes have already been implemented and respective PR's are linked t=
o
> >> the
> >> RFC.
> >>
> >> You can find the RFC at
> >> https://wiki.php.net/rfc/language-constructs-syntax-changes
> >>
> >> There is no BC break!
> >> Proposed changes only allow certain constructs to be considered valid.
> >>
> >
> > I don't think introducing alternative syntax for declare and
> halt_compiler
> > is a good idea. It introduces two ways to write the same thing, without
> > much benefit I can see.
> >
> > Your stated goal is to make it clearer that these aren't functions, but
> > language constructs. I'm not sure your change helps that much: While
> > "__halt_compiler()" looks like a function call, "__halt_compiler" looks
> > like a constant lookup. For the declare syntax, "declare(a =3D 1)" is
> already
> > illegal syntax for functions, even with the parentheses.
> >
>
> I can agree with "__halt_compiler;" similar to constant lookup, which
> indeed does not mate it more clear.
>
> Regarding the second syntax for "declare" what I wanted to achieve is
> reduce the number of different syntaxes and we do have quite a few in PHP=
.
> I've noticed that the "declare" syntax is quite similar to the const
> declare if you simply remove parentheses,
> which therefore IMO increases readability, consider this example:
>
> declare strict_types =3D 1;
> const GEAR_LIMIT =3D 5;
>
> From parser perspective, these both use const_list and only differ by a
> first keyword and looks similar and present the same syntax construct.
> Which currently is not true and they're both presented as a different
> syntax.
>
> By introducing an alternative syntax I planned to deprecate the old as so=
on
> as we could potentially do that.
> I believe it'd be hard until we have ticks directive.
>
> Cheers,
> --
> Micha=C5=82 Marcin Brzuchalski
>

--000000000000cd02c605aa5110e0--