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

Re: Pre-RFC: Optional Chaining

Thread Previous | Thread Next
From:
Martijn Lievaart
Date:
June 5, 2022 18:22
Subject:
Re: Pre-RFC: Optional Chaining
Message ID:
9714138b-4c97-2db7-9767-9e826c499f6b@rtij.nl

Op 05-06-2022 om 01:15 schreef Oodler 577 via perl5-porters:
> * breno <oainikusama@gmail.com> [2022-06-04 00:04:36 -0300]:
>
>> On Fri, Jun 3, 2022 at 5:38 PM Ricardo Signes <perl.p5p@rjbs.manxome.org>
>> 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


I'ld say, it should be exactly as garu/breno described, exactly his 
equivalent. It returns undef unless EXPR1 is defined, else it 
dereferences. Which may give errors and/or warnings, exactly as the 
equivalent statement.


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


No, as I understand it, it is just scalar (return undef) versus list 
context (return empty list). Makes a lot of sense.


HTH,

M4



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