Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88061
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.111.76 as permitted sender)
Message-ID: <BLU436-SMTP90D8DBFC51F9EED4F7D0D0E2550@phx.gbl>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_0BD6E453-018A-46AD-9D44-AC53D2C52FBA"
MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
In-Reply-To: <55EC1B77.6080708@telia.com>
Date: Sun, 6 Sep 2015 16:01:38 +0200
CC: PHP Internals <internals@lists.php.net>
References: <BLU436-SMTP13020F8CE8795C628BDC665E26B0@phx.gbl> <55EAB740.6080004@telia.com> <BLU436-SMTP18117F322FF7AF41A325E78E2560@phx.gbl> <55EC1B77.6080708@telia.com>
To: =?utf-8?Q?Bj=C3=B6rn_Larsson?= <bjorn.x.larsson@telia.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Short Closures
From: bobwei9@hotmail.com (Bob Weinand)

--Apple-Mail=_0BD6E453-018A-46AD-9D44-AC53D2C52FBA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="windows-1252"

> Am 06.09.2015 um 12:54 schrieb Bj=F6rn Larsson =
<bjorn.x.larsson@telia.com>:
>=20
> Den 2015-09-05 kl. 14:47, skrev Bob Weinand:
>>> Am 05.09.2015 um 11:34 schrieb Bj=F6rn Larsson =
<bjorn.x.larsson@telia.com <mailto:bjorn.x.larsson@telia.com>>:
>>>=20
>>> Den 2015-08-31 kl. 21:29, skrev Bob Weinand:
>>>> I had this RFC in draft since some time, but delayed it due to all =
the ongoing PHP 7 discussions. Also we have no master branch to merge =
features in until 5.4 EOL. Thus I'm reviving this now.
>>>>=20
>>>> Time for the first RFC targeting PHP 7.1 (assuming PHP 8 isn't =
going to be the next version ;-)):
>>>>=20
>>>> The short Closures RFC:
>>>> https://wiki.php.net/rfc/short_closures =
<https://wiki.php.net/rfc/short_closures>
>>>>=20
>>>> Hoping for constructive feedback,
>>>> Bob
>>>=20
>>> Why not supporting default values for arguments like the existing =
syntax?
>>> Also, if it's easy to implement return types, why not? I know it's =
half-baked
>>> but it was a separate RFC for 7.0.
>>>=20
>>> Regards //Bj=F6rn Larsson
>>=20
>>=20
>> Try adding
>>=20
>> | T_VARIABLE '=3D' expr { $$ =3D zend_ast_create_ex(ZEND_AST_PARAM, =
0, NULL, $1, $3); }
>>=20
>> in zend_language_parser.y on line 638 (in the current short Closures =
patch: =
https://github.com/php/php-src/blob/4fec999907068909c93047246cae62e64c16d8=
db/Zend/zend_language_parser.y#L634 =
<https://github.com/php/php-src/blob/4fec999907068909c93047246cae62e64c16d=
8db/Zend/zend_language_parser.y#L634>)
>>=20
>> You'll get a shift/reduce conflict, which I'm unable to resolve; if =
anyone knows how to, always appreciated. [Sure, I can just shift, but =
that'll lead to a parse error for legitimate ($var =3D 1) + 2 for =
example as it expects a ~> then.]
>> Similar reasons are for types; if anyone gets these fully =
implemented, I'll consider adding them ;-)
>>=20
>> Bob
> Aha, I see. Not being a compiler experts myself I wonder if
> any of the amendments Rowan proposed would help out?
>=20
> Another idea, is if Hack implementation could help finding
> a solution?
>=20
> //Bj=F6rn

No, these won't help there. And anyway, I doubt the use cases for short =
Closures match these where you'd need default values. =85 You anyway =
need these rarely and I guess you'll miss these even more with short =
Closures. After all, nothing prevents it from being added in a later =
RFC, when we find a solution for that.

Also, Hack is using a completely different parser, doesn't look like we =
could borrow anything there.

Bob=

--Apple-Mail=_0BD6E453-018A-46AD-9D44-AC53D2C52FBA--