develooper Front page | perl.perl5.porters | Postings from June 2021

Re: RFC: Multiple-alias syntax for for

Thread Previous | Thread Next
Dan Book
June 10, 2021 08:25
Re: RFC: Multiple-alias syntax for for
Message ID:
On Thu, Jun 10, 2021 at 3:28 AM Nicholas Clark <> wrote:

> I admit some guilt and inconsistency here - *I* preferred using `for` in
> the code examples because it's 4 characters shorter.
> *but* I realised that that makes the title `Multiple-alias syntax for for`
> which is daft. So I changed *that* to `foreach`. And now it's inconsistent.
> Bad programmer, no cookie.
> I don't know what is best.

My preference is to refer to the syntax construct descriptively as
"foreach", since although it is an exact synonym in the grammar, the
C-style for loop is never referred to as a "foreach". Separately from what
any person may decide to write in the actual code.

> > for my ($a, $b, $c) (@array) { … } # int($#array / 3) + ($#array % 3)
> > iterations?
> This is a question that has to be decided...
> What happens here if the list count isn't an integer multiple of 3?
> To me, the most obvious answer was substitute undef if it's not
> (ie don't die, and don't ignore what would be incomplete 'tuples' at the
> end)
> So if the list has 10 elements, it iterates as
>     One     Two     Three
>     Four    Five    Six
>     Seven   Eight   Nine
>     Ten     undef   undef
> and with 11, that last iteration is
>     Ten     Eleven  undef

This was my assumption as well and seems the most reasonable thing to do.
It's consistent with regular list assignment.

> > for my ($a, $b, undef) ((1,2,3)) { … } # one iteration or syntax error--
> Right. This is the interesting question...
> I'm suggesting syntax error.
> I think the slightly better question would be express it as
>     for my ($a, undef, $c) (1 .. 9) { ... }
> It's a reasonable generalisation of list assignment, where you can assign
> to
> undef to mean "ignore this value". I can see that this *might* be useful.
> It's also safe syntax to implement (although I didn't try, and I'm not sure
> how hard it would be).
> I'd like to stick to forbidding this, because it makes the implementation
> harder.

I also see how it could be useful, but on the other hand it is exactly the
same in practice as my ($x, $y, $z) but with some (imagined or real)
microoptimization of not aliasing the second value/using up that variable
name. I don't think it's useful enough to outweigh complication to the


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About