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 ?

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
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>

Reply via email to