Re: [RFC] [Discussion] Short Closures

> Am 06.09.2015 um 12:54 schrieb Björn Larsson <bjorn.x.larsson@telia.com>: > > Den 2015-09-05 kl. 14:47, skrev Bob Weinand: >>> Am 05.09.2015 um 11:34 schrieb Björn Larsson <bjorn.x.larsson@telia.com >>> <mailto:bjorn.x.larsson@telia.com>>: >>> >>> 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. >>>> >>>> Time for the first RFC targeting PHP 7.1 (assuming PHP 8 isn't going to be the >>>> next version ;-)): >>>> >>>> The short Closures RFC: >>>> https://wiki.php.net/rfc/short_closures >>>> <https://wiki.php.net/rfc/short_closures> >>>> >>>> Hoping for constructive feedback, >>>> Bob >>> >>> 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. >>> >>> Regards //Björn Larsson >> >> >> Try adding >> >> | T_VARIABLE '=' expr { $$ = zend_ast_create_ex(ZEND_AST_PARAM, 0, NULL, $1, $3); >> } >> >> in zend_language_parser.y on line 638 (in the current short Closures patch: >> https://github.com/php/php-src/blob/4fec999907068909c93047246cae62e64c16d8db/Zend/zend_language_parser.y#L634 >> <¹Y¤Â³ >> q%—Žôì%https://github.com/php/php-src/blob/4fec999907068909c93047246cae62e64c16d8db/Zend/zend_language_parser.y#L634>) >> >> 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 = 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 ;-) >> >> Bob > Aha, I see. Not being a compiler experts myself I wonder if > any of the amendments Rowan proposed would help out? > > Another idea, is if Hack implementation could help finding > a solution? > > //Björn No, these won't help there. And anyway, I doubt the use cases for short Closures match these where you'd need default values. … 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