Front page | perl.perl5.porters |
Postings from June 2022
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, M4Thread Previous | Thread Next