Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88410
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.213.46 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAL=_i_=wR5e3Bv++pKwMZcBJoF+0tVsXuRHnZYpa4wnq+cBdWg@mail.gmail.com>
References: <BLU436-SMTP156E8D7D141A710541FCA0FE2450@phx.gbl>
	<CA+9eiLtfxLNCMra1Xj9PEhAFZB+h903AK1rmWSQAH4SqQm2qCQ@mail.gmail.com>
	<CAL=_i_=wR5e3Bv++pKwMZcBJoF+0tVsXuRHnZYpa4wnq+cBdWg@mail.gmail.com>
Date: Tue, 22 Sep 2015 18:36:32 +0300
Message-ID: <CA+9eiLtVxiohBkQeDbP_aDtTdwQD_8p46gT73bikQTKKi8rHSQ@mail.gmail.com>
To: Joe Watkins <pthreads@pthreads.org>
Cc: Bob Weinand <bobwei9@hotmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11450f402d02b5052057c389
Subject: Re: [PHP-DEV] [RFC] [VOTE] Short Closures
From: dmitry@zend.com (Dmitry Stogov)

--001a11450f402d02b5052057c389
Content-Type: text/plain; charset=UTF-8

On Tue, Sep 22, 2015 at 4:54 PM, Joe Watkins <pthreads@pthreads.org> wrote:

> I'd really like to understand what you're trying to say there Dmitry, but
> I don't get it.
>
> What is your example function trying to show ?
>
> As it mentions in the RFC, vars in short closure are by-value, so I can't
> see what side effects you might be thinking of ?
>

It's clear to me that foo() will return NULL, but how many warnings about
unused variable $y will we get?

Thanks. Dmitry.


>
> Cheers
> Joe
>
> On Tue, Sep 22, 2015 at 9:25 AM, Dmitry Stogov <dmitry@zend.com> wrote:
>
>> I'm against the magic - "automatically use () all of the (compiled)
>> variables".
>> I'm also against compound short closures with curly brackets.
>> in my opinion they opens too many ambiguous questions.
>>
>> function foo() {
>>   (($x) ~> {$y = 3; return $y + $x;})(5);
>>   return $y;
>> }
>>
>> also think about nested closures and use of variables from not direct
>> enclosure.
>>
>> I'm not sure if we need all "functional programming" features in PHP, but
>> if we introduce them, lets do it consistently with the existing language.
>> I think, this proposal can't be approved without support for type hinting.
>>
>> Thanks. Dmitry.
>>
>> On Tue, Sep 22, 2015 at 4: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
>> >
>> >
>>
>
>

--001a11450f402d02b5052057c389--