Re: [RFC] [VOTE] Short Closures

On Tue, Sep 22, 2015 at 3:59 AM, Bob Weinand <bobwei9@hotmail.com> wrote: > Hey, > > Thanks for all your feedback in the discussion thread! > > So, before I start the vote, just two quick notes: > I've added two notes about the statement syntax and the single variable use. > Though a few people complained, I'm not switching to the ==> operator, as I noticed > many people expected typehints to work (they don't due to parser limitations) when they > compared to Hack's short Closures. It also allows us to differ syntax-wise [e.g. for typehints] > from Hack without causing any confusion later. Which should be the smartest choice: Avoid conflicts. > (If anyone strongly feels against that, he may vote no, but I would like to not bikeshed that in > this Vote thread, but leave it free for eventual actual issues.) > > Now, the link to the RFC about Short Closures: > https://wiki.php.net/rfc/short_closures > or straight ahead to the vote: > https://wiki.php.net/rfc/short_closures#vote > > Thanks, > Bob > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > Hello, since the RFC doesn't look like it will pass, I have a question about RFC process - will you be able to "fix" the RFC and submit it for vote again with targeting PHP 7.1? The biggest issues seem to be - ~> operator instead of ==> - missing type hints - auto imports If probably the first two would be resolved, then maybe the RFC could get accepted? I personally don't understand the 3rd complain, since having to use() everything would make it "not-so-short closures". I also remember people not liking the option not to have parenthesis with single parameter. I was thinking about this, and with the type hints, it would be probably better anyways to have the ( ) required, so that would be just a single use case where they wouldn't be required - so is there a point in keeping this special use case? Regards Pavel Kouřil