and maybe one day if public, protected, private, interface, abstract i.e
java impurities are finally removed:
class bar
{
owned var $m_a : float = 0.0;
var $b : object = null;
fn foo(int $x, int $y) : int
{ return fn($x) [&$y] { $x * $y; }; }
owned fn bar() : void
{ return; }
}
On Tue, Apr 9, 2019 at 5:33 PM M. W. Moe <mo.mu....@gmail.com> wrote:
> 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
>>
>
