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

Re: RFC: Multiple-alias syntax for for

Thread Previous | Thread Next
From:
Dan Book
Date:
June 10, 2021 15:40
Subject:
Re: RFC: Multiple-alias syntax for for
Message ID:
CABMkAVXQqk_XaUwvotmOnZ2vE6QsX6HkngdCr0Msph4RM9PxdA@mail.gmail.com
On Thu, Jun 10, 2021 at 9:27 AM <hv@crypt.org> wrote:

> Nicholas Clark <nick@ccl4.org> 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
> error.
>

Agreed, if it is an error now, it is trivial (design wise, at least) to add
support for it later.

-Dan

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About