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

Re: RFC: Multiple-alias syntax for for

Thread Previous | Thread Next
June 10, 2021 13:27
Re: RFC: Multiple-alias syntax for for
Message ID:
Nicholas Clark <> wrote:
: ## Rejected Ideas
:+### Permit `undef` in the list of scalars
:+    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).
:+But it adds considerable runtime complexity. The easiest implementation is if there are exactly *n* scalars, all declared in the `for` loop itself, because this way they occupy adjacent Pad slots. This means that there is only one extra integer to store in the optree, which used both to calculate the *n*-at-a-time **and** the addresses of the target variables.
:+Adding `undef` to the mix rules out a simple, clear implementation.

I'd like to add a vote for this to move from "rejected" to something
like "possible future extension", to capture the notion that "if we were
to support semantics like this, this is the syntax we'd want to use,
but we don't plan to support this for the first draft of the feature".

More generally, I think we should be slow to use "rejected" in this
context: as part of the record of an RFC process, that at least
somewhat implies "rejected for ever" - we're never going to want this
in the language. Certainly it sounds stronger than "I've chosen not
to put that in the first implementation".

(I do appreciate that all the information is there in the detail.
I just worry that labels tend to be sticky.)

The additional implication is that we should have tests in the first
implementation to assert that the extended syntax remains a syntax


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