Dmitry,
On Tue, Sep 22, 2015 at 2:05 PM, Dmitry Stogov <dmi...@zend.com> wrote:
> On Tue, Sep 22, 2015 at 7:01 PM, Bob Weinand <bobw...@hotmail.com> wrote:
>
>>
>> > Am 22.09.2015 um 17:36 schrieb Dmitry Stogov <dmi...@zend.com>:
>> >
>> > On Tue, Sep 22, 2015 at 4:54 PM, Joe Watkins <pthre...@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 <dmi...@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 <bobw...@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
>>
>>
>> Notice: Undefined variable: y in php shell code on line 3
>>
>> It just yields exactly one notice about the inexistent $y (as it obviously
>> does not leak through the scope): by-value binding.
>>
>> I'm not sure what your issue here is?
>>
>
> The current PHP version emits two warning on similar constructs, and this
> is explainable because we explicitly "use" $y.
>
> $ sapi/cli/php -r 'function foo(){(function($x) use ($y){$y=3; return
> $y+$x;})(5);return $y;} var_dump(foo());'
> PHP Notice: Undefined variable: y in Command line code on line 1
>
> PHP Notice: Undefined variable: y in Command line code on line 1
>
> NULL
>
There's an important distinction here. The explicit `use($y)` triggers
a notice because you said to use an undefined variable.
function foo() {
(($x) ~> {$y = 3; return $y + $x;})(5);
return $y;
}
In this case, there's no practical binding of `$y` at all. The `$y` in
the scope of the closure is never actually read from before it is
assigned to. Meaning the variable doesn't need to exist prior to that
assignment, meaning that it doesn't have to be bound (used), and as
such shouldn't throw a notice.
This becomes a ton easier if we ever move to an explicit CFG+SSA
compile step. Then, we can see which variables dominate the closure to
see what needs to be bound vs what doesn't. In this example, converted
to SSA, you'd see:
function foo() {
$y1 = 12;
(($x1) ~> {$y2 = 3; return $y2 + $x1;})(5);
return $y1;
}
Hence you can see that `$y2` is truly an independent variable, and
hence `$y1` never needs to be bound (and hence no notice).
So your case of explicitly using `$y` isn't actually what's happening
with the closure (at least with respect to userland behavior). Hence
why the lack of notice exists.
My $0.02 at least,
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
