Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105187
MIME-Version: 1.0
References: <CAF+90c9YZcrquGfS4h3x1a+codkCFLarAThsOXcN69RCTvbAFA@mail.gmail.com>
 <CAF+90c_keZTbMTuDO+9WRa53MsYxbNxkMO_pxGyymGnxCp691g@mail.gmail.com>
In-Reply-To: <CAF+90c_keZTbMTuDO+9WRa53MsYxbNxkMO_pxGyymGnxCp691g@mail.gmail.com>
Date: Wed, 10 Apr 2019 05:29:32 +0700
Message-ID: <CAP=w73UPiNPgnr-=OkRt84LcF-WocuryUu890oay1XJ=q9UcSQ@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000ca0e990586207c01"
Subject: Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures
From: webdevxp.com@gmail.com (Kosit Supanyo)

--000000000000ca0e990586207c01
Content-Type: text/plain; charset="UTF-8"

Hi internals,

This is my first write to this list but I've been followed
your discussions quite a while ago. For a brief introduction,
my name is Kosit, I'm a programmer from Thailand and I've been using
PHP since version 3 (for a short period before moving to PHP4).

I'm a fan of `fn` syntax and OK to go with it but I would like to
propose some extended syntax & behavior about binding.

What if we can omit the `use` keyword at all and use only
second parentheses for variable & reference binding
and make the presence of second parentheses turn off implicit variable
binding.

    $a = 0;
    $f1 = fn(): int => $a;
    $b = 0;
    $f2 = fn(): int () => $b;

equivalent to

    $a = 0;
    $f1 = function () use ($a) { return $a; };
    $b = 0;
    $f2 = function () { return $b; };

And what if we can omit parentheses at all if fn has no parameters.

    $f = fn => $this->doSomethingWithAB($a, $b);
    $multiStmtBody = fn {
        // ...
    };

When people want to import references (and addtional variables)
they have to do it explicitly like before but without `use` keyword.

    $f = fn($y): array (&$arr, $x) => $this->doSomethingWithArrAndXY($arr,
$x, $y);

equivalent to

    $f = function ($y): array use (&$arr, $x) {
        return $this->doSomethingWithArrAndXY($arr, $x, $y);
    };

Second parens without `use` keyword may be ugly but can be seen as
an abbreviation of old closure syntax.

This can eliminate possible problems of reference binding (switching) syntax
described in the RFC that may cause undesired behavior and performance
problem
because `use (&)` will make all variables by-reference bound.

Summary:

1. No `use` keyword for binding.
2. The presence of second parentheses will turn off implicit binding.
3. Can omit parentheses if fn has no parameters.

I apologize in advance for my bad English
but I hope my idea can be taken into consideration
or at least can be transformed into another useful idea.

Regards,
Kosit

On Mon, Apr 8, 2019 at 9:07 PM Nikita Popov <nikita.ppv@gmail.com> wrote:
>
> On Wed, Mar 13, 2019 at 4:56 PM Nikita Popov <nikita.ppv@gmail.com> wrote:
>
> > Hi internals,
> >
> > Motivated by the recent list comprehensions RFC, I think it's time we
took
> > another look at short closures:
> >
> > https://wiki.php.net/rfc/arrow_functions_v2
> >
> > This is based on a previous (withdrawn) proposal by Levi & Bob. It uses
> > the syntax
> >
> >     fn($x) => $x * $multiplier
> >
> > and implicit by-value variable binding. This example is roughly
equivalent
> > to:
> >
> >     function($x) use($multiplier) { return $x * $multiplier; }
> >
> > The RFC contains a detailed discussion of syntax choices and binding
modes.
> >
> > Regards,
> > Nikita
> >
>
> Heads up: I plan to start voting on this RFC tomorrow if nothing new comes
> up.
>
> Most of the discussion was (as expected) about the choice of syntax.
> Ultimately I think there are many reasonable choices we can make here, but
> we should stick to a specific proposal for the purposes of the RFC vote.
> None of the given arguments convinced me that some other syntax is
> *strictly* better than the proposed fn($x, $y) => $x*$y -- it's more a
> matter of some choices being slightly better in one case and slightly
worse
> in another. My personal runner-up would be \($x, $y) => $x*$y, but I
> suspect that there are some people who are more strongly biased against
> "sigil salad" than I am...
>
> Nikita

--000000000000ca0e990586207c01--