Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:98066 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 73772 invoked from network); 31 Jan 2017 09:32:40 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 31 Jan 2017 09:32:40 -0000 Authentication-Results: pb1.pair.com smtp.mail=ilija.tovilo@me.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=ilija.tovilo@me.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain me.com designates 17.110.69.252 as permitted sender) X-PHP-List-Original-Sender: ilija.tovilo@me.com X-Host-Fingerprint: 17.110.69.252 mr11p00im-asmtp001.me.com Received: from [17.110.69.252] ([17.110.69.252:37485] helo=mr11p00im-asmtp001.me.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 4B/E0-51557-4B950985 for ; Tue, 31 Jan 2017 04:32:37 -0500 Received: from process-dkim-sign-daemon.mr11p00im-asmtp001.me.com by mr11p00im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OKN00C0015EEW00@mr11p00im-asmtp001.me.com> for internals@lists.php.net; Tue, 31 Jan 2017 09:32:34 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=4d515a; t=1485855154; bh=myqseRl7irIj+mgaQ8jHez2PazQXf/sGds+o+Avnkaw=; h=MIME-version:Content-type:To:From:Subject:Date:Message-id; b=i1nxvA4EoqkXQgYXGDx8ET1Zs6SQd16gjFkunEaNpkzf77yfYJTvoZIRYBPdEMXSS w+8s1Ekb1ucLmWNbSUG2/wxnWIgXQhHJw4JcR59w+cO84OMAx4T61L6/AmpmDcJSKa rbUHQO+hpvyVt3vZSq3j168rHcWJ6YgLJmD6JDpqrO4u8S+M9zAAgVvJG7lSfr/KIj +QRC2v0N+eyOUqFxgyEMtNsVYH2Z+VeQZC8DiKPUEYC4ivrUdeprMYO7UNM0C9YzFA 8cJVqhsojldGhtesdNpQsZ6sJeKuhu4T9zF9uOl+mCpoO02yU/tWPjEkylAo05Dkft +PsFrY3QHFRbQ== Received: from st11p02im-spool002.me.com ([17.172.220.214]) by mr11p00im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTP id <0OKN00M2G167BX50@mr11p00im-asmtp001.me.com>; Tue, 31 Jan 2017 09:32:32 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-01-31_04:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603290000 definitions=main-1701310084 MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_axrvG8r9Yos5s+N6w9nOVw)" Received: from localhost ([17.172.220.222]) by st11p02im-spool002.mac.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTP id <0OKN00CH7167JB50@st11p02im-spool002.mac.com>; Tue, 31 Jan 2017 09:32:31 +0000 (GMT) To: Nikita Nefedov Cc: internals , Levi Morrison Date: Tue, 31 Jan 2017 09:32:31 +0000 (GMT) X-Mailer: iCloud MailClient17AProject113 MailServer17A64.25820-16A-1674-d2878f132b2c X-Originating-IP: [213.221.233.50] Message-ID: Subject: Re: [PHP-DEV] [RFC][Discuss] Arrow Functions From: ilija.tovilo@me.com (Ilija Tovilo) --Boundary_(ID_axrvG8r9Yos5s+N6w9nOVw) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT I agree. Using the prefix `function` kind of defeats the purpose of the whole RFC. There are three things that contribute to the boilerplate of closures: - The `function` keyword - The `return` keyword - The `use` clause The RFC eliminates two and reduces one to about 25%. I also dislike the idea to use `fn($x, $y => $x + $y)` kind of syntax for two reasons: 1. To anyone who knows arrow functions fron any other language, this looks like a function call 2. Optically, `$x` and `$y => $x + $y` look like separate parameters Also, as mentioned in the RFC adding the `fn` keyword only has very minor backwards compatibility issues. Regards, Ilija On 31 Jan, 2017, at 09:24 AM, Nikita Nefedov wrote: On Mon, 30 Jan 2017 20:55:07 +0300, Levi Morrison wrote: Bob Weinand and I are happy to announce that the [Arrow Functions][1] RFC is moving into the public discussion phase. We have been collaborating on this RFC for many months now and finally have a proposal we are happy to discuss in the open. Here is an example of an existing closure: function ($x) use ($arr) { return $arr[$x]; } This RFC proposes syntax and semantics to simplify this common usage to: fn($x) => $arr[$x] More details are in the RFC. The [implementation][2] currently has no known issues and is ready for you to download, build and test, which we encourage you to do. We look forward to a productive discussion period and are happy to answer questions. For historical purposes, the revision of this RFC is currently at [1485798604][3]. [1]: https://wiki.php.net/rfc/arrow_functions [2]: https://github.com/morrisonlevi/php-src/tree/arrow_functions [3]: https://wiki.php.net/rfc/arrow_functions?rev=1485798604 Hey Levi, Bob, that looks very good. The fn prefix is peculiar yes but it's alright, it doesn't harm neither readability nor writability, it even has some precedences in other languages (think Rust, Elixir) and as we all know it is necessary for parser. Thanks for the work, I hope it lands in PHP. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php --Boundary_(ID_axrvG8r9Yos5s+N6w9nOVw) Content-type: multipart/related; boundary="Boundary_(ID_ZkGP0CJ+k35qITkdQQ/bIg)"; type="text/html" --Boundary_(ID_ZkGP0CJ+k35qITkdQQ/bIg) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
I agree. Using the prefix `function` kind of defeats the purpose of t= he whole RFC.
There are three things that contribute to the= boilerplate of closures:

- The `function` keyword
- The `return` keyword
- The `= use` clause

The RFC eliminates two and reduces one to about 25%.

I also dislike= the idea to use `fn($x, $y =3D> $x + $y)` kind of syntax for two reaso= ns:

1. To anyone who knows arrow functions fron any other language, this look= s like a function call
2. Optically, `$= x` and `$y =3D> $x + $y` look like separate parameters

Also, as mentioned in the RFC adding the `fn= ` keyword only has very minor backwards compatibility issues.

Regards,
Ilija

= On 31 Jan, 2017, at 09:24 AM, Nikita Nefedov <inefedor@gmail.com> wr= ote:

On Mon, 30 Jan 2017 20= :55:07 +0300, Levi Morrison <levim@php.net> wrote:

Bob Weinand and I are happy to= announce that the [Arrow Functions][1]
RFC is moving into the public discussion p= hase. We have been
collaborating on this RFC for many months now and finally have = a
propos= al we are happy to discuss in the open.

Here is an example of an existing closure:

function ($x)= use ($arr) {
return $arr[$x];
}

This RFC proposes syntax and semantics to simplify this common usage= to:
fn($x)= =3D> $arr[$x]

More details are in the RFC. The [implementation][2] currently has = no
known= issues and is ready for you to download, build and test, which
we encourage you t= o do.
We lo= ok forward to a productive discussion period and are happy to
=
answer questions.

For historica= l purposes, the revision of this RFC is currently at
[1485798604][3].
=

[1]: https://wiki.php.net/rfc/arrow_functions
[2]: https://github.com/morrisonlevi/php-src/tree/arrow_functi= ons
[3]: https://wiki.php.net/rfc/arrow_functions?rev=3D= 1485798604

Hey Levi, Bob,
=
that looks very good.

The fn prefix is peculiar yes but it's al= right, it doesn't harm neither
readability nor writability, it even has= some precedences in other
languages (think Rust, Elixir) and as we all= know it is necessary for
parser.

Thanks for the work, I hope it= lands in PHP.

--
PHP Internals - PHP Runtime Development Maili= ng List
To unsubscribe, visit: http://www.php.net/unsub.p= hp

= --Boundary_(ID_ZkGP0CJ+k35qITkdQQ/bIg)-- --Boundary_(ID_axrvG8r9Yos5s+N6w9nOVw)--