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. :)

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to