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

Re: Pre-RFC: Optional Chaining

Thread Previous | Thread Next
Oodler 577 via perl5-porters
June 4, 2022 23:15
Re: Pre-RFC: Optional Chaining
Message ID:
* breno <> [2022-06-04 00:04:36 -0300]:

> On Fri, Jun 3, 2022 at 5:38 PM Ricardo Signes <>
> wrote:
> > Having re-read the posts, I think there was a lot of work in the weeds,
> > and the pre-RFC question sounds like "yes of course people would like
> > something like this," and then we get to the actual RFC question.  But
> > Breno's pre-RFC was basically an RFC and could be filed as such, then to be
> > worked on until ready for someone to have a crack at implementing.
> >
> That's terrific, thank you all for considering this proposition!

Idk why all the static about it being to well developed. I think it's great
and shows a lot of thought. A pre-RFC should be the seed from which the RFC
springs; so why not show up with something that's a little more mature? I
think root of the complaint is "give me the executive summary before I spend
time reading though this" - which I think is fair. But if that was part of
it who cares how long it is?

> My comments on the PSC call this morning were mostly that I felt the most
> > valuable simplification would be to provide an explanation of ?-> in terms
> > of what it's equivalent to.  For example:
> >
> > EXPR1 ?-> EXPR2
> >
> > # is equivalent to
> >
> > defined EXPR1 ? EXPR1->EXPR2 : undef
> >
> > # with the caveat that EXPR1 is only evaluated once

I like this, but what distinction does "defined" or "truthy"
hold with references?

It seems necessary for this to even be "true", the following
conditions must hold:

* it's not undef
* it's blessed
* it "can" EXPR2

> >
> >
> Perfect, except I think it really should address the empty list case by
> returning () (which becomes undef in scalar context) instead of always
> returning plain undef:
>    defined EXPR1 ? EXPR1->EXPR2 : ()
> So we can also write:
>     push @list, $item?->foo;   # does NOT add undef to @list when $item is
> undef

Seems like this suggests a failure of $item?->foo throws an exception so
is there some implicit try/catch here or is "push" supposed to now know
about this; or is it more like this:

     push @list, eval { $item?->foo }; # which doesn't fulfill the "don't add ..."

But maybe more like this is the desired behavior?

     local $@;
     my $added_ok = eval { push @list, $item?->foo }
     # now maybe check if $added_ok or if $@ has something in it?

So I think that while useful, ->? way necessarily need to return "undef", but I still
think this is useful if you have a single step to filter out the undefs.

Or maybe something like this, that would collect anything that has no reachable
"wang" routine for whatever reason gets collectde into the 'unknown' key:

     my $bucket = {};
     foreach my $thing (@stuff) {
       push @{$bucket=>{$thing->?wang} // q{unknown}}, $thing;

>     @list = $arrayref?->@*;    # if $arrayref is undef, @list stays empty
> and not (undef)

Again, this is cutting across a lot of things knowing what the failure
mode of "?->" is and doing something reasonable with it.

> I think the objection (made by a few, including me) that we need to use
> > "defined" (as I do in the snippet above) rather than "ref" as the test
> > should be taken into account in any re-submission of the RFC.
> >
> I agree with the objection and I am very much ok with it using "defined"
> instead of "ref", and volunteer to work on an updated version of the
> original document, to be resubmitted as an exploratory RFC back to the
> group or as a PR, at the PSC's discretion.
> >
> >
> > But is there anything left to do but?
> >
> >    1. submit the RFC in an updated form
> >    2. discuss whether it's ready to implement in that form
> >    3. eventually say it's ready for implementing

4. implement it and sheperd it for the next 20 years.

And just to be clear, I think a "?->" that does something to help to create or
improve existing idioms is great. What it actually does, that's the point
of the RFC process, which basically is what everyone else has said..


> >
> > ?
> >
> I'd like to address some observations made before regarding the proposal,
> but I'll do it in a separate email.
> Cheers!
> garu

SDF-EU Public Access UNIX System - #openmp #pdl #native

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