Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:104880 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 46361 invoked from network); 23 Mar 2019 01:08:57 -0000 Received: from unknown (HELO lb2-smtp-cloud7.xs4all.net) (194.109.24.28) by pb1.pair.com with SMTP; 23 Mar 2019 01:08:57 -0000 Received: from [IPv6:2001:983:6fc5:1:1170:95eb:8ca6:2a5c] ([IPv6:2001:983:6fc5:1:1170:95eb:8ca6:2a5c]) by smtp-cloud7.xs4all.net with ESMTPA id 7SE7hM5kUNG8z7SE9h7uSf; Fri, 22 Mar 2019 23:01:25 +0100 To: internals@lists.php.net References: <85417a73-a391-c9ad-49aa-5b88c65b0900@gmail.com> <5c8ea43d.1c69fb81.e50f1.7d18SMTPIN_ADDED_MISSING@mx.google.com> <0d34b3b1-866e-4bab-9a8f-3c70f1fc9721@www.fastmail.com> <752c83ab-0e6f-d8f5-ff15-e1f75b5d04b5@gmail.com> <301552a9-6f01-3177-0e57-3d9aac54cc0c@gmail.com> Message-ID: Date: Fri, 22 Mar 2019 23:01:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfJkb/ZOC57Kn+8tw/2tMbzoD/fnncA+ysp2iUY/VEXn38Gaak5BTltqXFo4znqTW62ow4PZaGFz1P4jhA6/SdMjNCpSrRxChDQ/SxkZfQL3ja8RPSz4e PggUPSQgit9iot8PBVw8Vl2fuT+At9ekt7zpovWkgCZP2LPEsR5ULYIzsVFLM6NmcQrb8d2bLeaSBUbtMF/A9XmUOeP1ukuTJ6MftbajmwQ4BuLL1a9pN++I 01G3bmtbx2eJHYcO6DG0yEixnqjxmEwGEq2/Bi6vNBs= Subject: Re: [PHP-DEV] RFC Draft: Comprehensions From: d.takken@xs4all.nl (Dik Takken) On 21-03-19 16:22, Larry Garfield wrote: > OTOH, if we just have the one syntax: > > [foreach $foo as $bar yield $bar*2] // gives a generator > > And include a nicer "fast-forward" operator than interator_to_array(), then we automatically get: > > ...[foreach $foo as $bar yield $bar*2] // turns the generator into an array on the fly > > Which is both easier to learn (two independently useful primitives, composed), easier to understand (because the latter is not as visually similar), and doesn't lay claim to two different potentially useful pieces of block syntax, leaving the other open for later use by some other idea later. That sums it up nicely, thanks. I agree that we should try to focus on the actual comprehension syntax and leave the problem of how to better support both generators and arrays to a future RFC. Still, I would like to mention one detail that is relevant _now_, for the discussion about the current RFC. Indeed, whether comprehensions will be used primarily for creating generators or arrays depends on the developer, libraries that are used, and so on. In my opinion, this calls for a syntax that is not biased towards either of the two. In the cases where comprehensions are mainly used to create arrays, the need to convert a generator into an array still feels like an extra hoop to jump through in order to get what you need. Even when all it takes is three dots. While this issue should be discussed separately, I mention it here to support my proposal to keep the option open to extend the syntax into a dual array / generator syntax in the future. In case we go for a syntax like $generator = (foreach $foo as $bar yield $bar*2) then we could still decide to introduce a variant like $array = [foreach $foo as $bar yield $bar*2] later, as proposed by Nikita. Going for a square bracketed syntax for generators right now will not allow this future extension. Until then, using the spread operator to materialize generators into arrays would be really nice. > Now can we go back to bikeshedding the actual syntax style to use, per my earlier email? :-) Sounds good. :)