Hello,
for now what I see is a bit of everything:
- adding a contextual keyword/alias to function
- enforce by reference
- a lack of coherence
too mockups (I like the arrow idea but won't ever replace `use`
functionalities)
"keeping the unnecessary arrow"
class bar
{
public fn foo(int $x, int $y)
{
return fn($x) [&$y] => {
$x * $y;
};
}
}
"aliasing function keyword to fn; aliasing use keyword with brackets
syntax"
class bar
{
public fn foo(int $x, int $y)
{
return fn($x) [&$y] { $x * $y; }
}
}
On Tue, Apr 9, 2019 at 3:29 PM Kosit Supanyo <webdevxp....@gmail.com> wrote:
> 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....@gmail.com> wrote:
> >
> > On Wed, Mar 13, 2019 at 4:56 PM Nikita Popov <nikita....@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
>
