Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99628
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.170 as permitted sender)
Date: Fri, 23 Jun 2017 20:05:46 +0100
User-Agent: K-9 Mail for Android
In-Reply-To: <CADqTB_hmyp3NhS=Se-ioksWeV0_xQ4rRnvm+hmeMdcBRzngNGA@mail.gmail.com>
References: <CAFMT4Npoo_ZrRk-kk4C6KHYEtV93pU7Wmh0FhaPi6Z-9qkObaQ@mail.gmail.com> <5fe1eefe-1c4f-4c31-c975-ab6c768c977c@telia.com> <E56D1F4A-6DC7-47DA-BAD6-1722E017B048@me.com> <CADqTB_jDmFZZc3ah=J8F99P77qnuWVgXS5UwXgrbartCp5B+UQ@mail.gmail.com> <3C763609-54FC-480B-AE95-94A1873226E0@me.com> <CADqTB_hU+38TOHdaukhGBS-2NPq-PNSci1h078TPOGbE7WcmWg@mail.gmail.com> <9A3447BF-F982-4C5A-B55B-466036AF2E53@me.com> <CAFMT4NrdCRJxGyeGqLbAoaV896FN6VpDjY-68trXoaRgZe4VyQ@mail.gmail.com> <CADqTB_hT-Nd5wX129GgeQxL8RNJ85maSPOPHUt-2NK-ef3yF-g@mail.gmail.com> <CADqTB_hB1ifmXu4VO6Z4A3gN=2AF_PU4C8yCYXz8QN6zZ_k=6w@mail.gmail.com> <2d89daaa-056f-3dcb-a5f2-b790affe203a@garfieldtech.com> <CADqTB_gN+bdU9HBbyjpJJCK7FxO_rQi9hmEuhANGEkc52mpHtw@mail.gmail.com> <DC4F8FEC-7EAA-4D14-BD57-C48DC0A7D392@gmail.com> <CADqTB_jXUtjVMexZOScHN96sQYgLKdws6_rGCWV8MDriSe4hCQ@mail.gmail.com> <76f05ddb-fe72-fa90-e3a0-8e5233952aa1@gmail.com> <CADqTB_hmyp3NhS=Se-ioksWeV0_xQ4rRnvm+hmeMdcBRzngNGA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
CC: PHP internals <internals@lists.php.net>
Message-ID: <AAF87F0F-B6BA-46A1-94EC-952DA4751E7C@gmail.com>
Subject: Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions
From: rowan.collins@gmail.com (Rowan Collins)

On 23 June 2017 19:43:19 BST, Rasmus Schultz <rasmus@mindplay=2Edk> wrote:
>Suffice it to say, I understand your arguments and your point of view,
>I
>just don't agree with it

Indeed, as I say, different people want different things from this proposa=
l, and no syntax is going to suit all of them=2E I think this is important,=
 because it means the choice of syntax can never fully be separated from th=
e choice of feature set=2E

=20
>I'm a big non-believer in syntax alternatives for the same
>language-features for various use-cases

I have a lot of sympathy for this view, and it tempts me to say "if it ain=
't broke, don't fix it" - if the existing syntax covers all scenarios, why =
bother with a new one at all=2E I understand that your aim would be to repl=
ace the existing syntax, and perhaps in the distant future remove it altoge=
ther=2E

However, I would point out that a huge number of programming constructs ca=
n be considered special cases of others=2E For instance, every while loop c=
an be replaced with if and goto, but not every combination of if and goto c=
an be turned into a while loop; so at one logical extreme, we should remove=
 while loops from the language as redundant syntax for one special case=2E

Like most such decisions, it's a question of where you draw the line: in t=
his case, whether you think single-expression closures are a sufficiently c=
ommon and distinctive case that they deserve their own syntax=2E Evidently,=
 you think they are not; I have been reasonably convinced by examples peopl=
e have shown that they are=2E

Regards,

--=20
Rowan Collins
[IMSoP]