Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:105189 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 94340 invoked from network); 10 Apr 2019 03:53:42 -0000 Received: from unknown (HELO mail-lj1-f194.google.com) (209.85.208.194) by pb1.pair.com with SMTP; 10 Apr 2019 03:53:42 -0000 Received: by mail-lj1-f194.google.com with SMTP id f23so479208ljc.0 for ; Tue, 09 Apr 2019 17:50:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bbKn6iXFKcURjcBjP49uy/DC569R6UWBwGjfKnnUbZ8=; b=n3uO3mCxPFp+9/xhDMlOgg95t1NJSk9n4k+ldk2pum8ivbwLPTsibmCK3A2K5G7W+R yz1PmaIsZbFEZNe0JM/kw0ujSnLIye3x3muy3Hqqb+C+VVjSV2HG1dj7Y37fZcAzYTve z01hMzB8AtYdzuA7VopjsZXULU6Ufv4CMi6sSij9mx4rQgbv610kBFcBFUTAaJz+nxPl WwkovIYWV/W5A22GxXchoBYbiaka1g2J7e65mxcTNReFErPn5Jgsw0cET6wTJ2BtZr8T nGMNywqSlQ5yf8Lut/Rwi28Nc2+Hn13RlGklDc989a6vXieputOcARyTgQTNiaDWSf9P EzXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bbKn6iXFKcURjcBjP49uy/DC569R6UWBwGjfKnnUbZ8=; b=qGKYXeLhE/nErGZp/5yn2SgRDv4VRfblT2KY5nbvRpPxLruBDLE2oiDzqgBYb207yA iaj5t412ZhJKrIkaulmUUm5n21v6S9uYis9ENzEwMmCY5IRIKAY38FDNPhJwx1CNSbh3 F/l2ScgBUq12bCuNCMn6P1u8dRRO9YDAib07GT3gtklRaraPTcEvZR3jiBA4CAeUS7PS f40OzeSZ0bCbmCBiWXhDPYarW0yfsUMCypcsLn9yermLNuPlPNghUH35EG8ojKiXzLhV m9l6Thzl72ry600ENWWaChCReE5PzAXr/5WAoJbDIpLbeak04ZTecSl2ijP6pbRS0z+8 sdSA== X-Gm-Message-State: APjAAAVqY+FPjou67uBg1ZZDiOgE8lqWhXWliNf1lKXuFsnE8NjYd7+z /sBp94iyrZFFAqDX7DPxZo82WJPl2kOZP3WewjA= X-Google-Smtp-Source: APXvYqxNL+ik39n0ozQIrdnYuIofNg4WVOskJ8vu/m3eNdAyST8W1DywlNNZDVvDwNX7MrKS6qRGjqagMt7+QM+3YHk= X-Received: by 2002:a2e:8648:: with SMTP id i8mr21265394ljj.166.1554857442645; Tue, 09 Apr 2019 17:50:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Tue, 9 Apr 2019 17:50:31 -0700 Message-ID: To: Kosit Supanyo Cc: PHP internals Content-Type: multipart/alternative; boundary="0000000000008b9be60586227522" Subject: Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures From: mo.mu.wss@gmail.com ("M. W. Moe") --0000000000008b9be60586227522 Content-Type: text/plain; charset="UTF-8" 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 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 > 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 wrote: >> > >> > On Wed, Mar 13, 2019 at 4:56 PM Nikita Popov >> 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 >> > --0000000000008b9be60586227522--