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

Re: Pre-RFC: Optional Chaining

Thread Previous | Thread Next
Martijn Lievaart
June 5, 2022 18:22
Re: Pre-RFC: Optional Chaining
Message ID:

Op 05-06-2022 om 01:15 schreef Oodler 577 via perl5-porters:
> * 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

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.



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