Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88507
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <BLU436-SMTP156E8D7D141A710541FCA0FE2450@phx.gbl>
References: <BLU436-SMTP156E8D7D141A710541FCA0FE2450@phx.gbl>
Date: Sat, 26 Sep 2015 09:18:20 +0200
Message-ID: <CAB6YZuyWTRJ-E5dwR-UNsV-Ext8kZhdSGANH3m9UhfNMeA48yw@mail.gmail.com>
To: Bob Weinand <bobwei9@hotmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] [VOTE] Short Closures
From: pajousek@gmail.com (=?UTF-8?Q?Pavel_Kou=C5=99il?=)

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 u=
se.
> Though a few people complained, I'm not switching to the =3D=3D> operator=
, as I noticed many people expected typehints to work (they don't due to pa=
rser limitations) when they compared to Hack's short Closures. It also allo=
ws 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 actu=
al 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 =3D=3D>
- 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=C5=99il