Mailing List Archive

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!

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
>
>
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
@list = $arrayref?->@*; # if $arrayref is undef, @list stays empty
and not (undef)

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

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

Cheers!
garu

On Fri, Jun 3, 2022 at 5:38 PM Ricardo Signes <perl.p5p@rjbs.manxome.org>
wrote:

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

Some comments on questions that arose in the past:

* why just the deref arrow -> and not other tokens/operators (e.g. ?=~, ?=,
etc)

Because it's trying to solve the specific issue of having to test an entire
chain individually instead of just one value. There is prior literature on
languages that have gone the extra mile on this and it was considered more
trouble than benefit, and is one of the reasons PEP505 was still not
accepted - it tries to do too much.

* are optional expressions evaluated? e.g. $y = $x?->{$i++}?->[++$i]

I think the operator should short-circuit and not evaluate any expressions
further up the chain. Like what would happen if you replaced that with a
lot of &&, ternaries or if() clauses.

* is $foo?->{x}{y}{z} the same as $foo?->{x}?->{y}?->{z} ?

No. $foo?->{x}{y}{z} means $foo?->{x}->{y}->{z}. To optional-chain
everything you would have to be explicit. The reason behind this is you may
want to get the original error/warning/vivification somewhere down the
chain.

* how would it handle things like $foo?->{x}?->{y} = 42

Same as $foo->{x}{y} = 42 if defined $foo && defined $foo->{x} && defined
$foo->{x}{y} (except way more readable)

* will string interpolation work? e.g. "$foo?->{x} and $bar?->y()"

We could learn from postderef_qq and decide what to do. Rik's suggestion of
hiding it behind a feature flag (at least for now) feels right to me.
However, since it defaults to undef, it would still trigger a warning, so
maybe it could pick the empty string as fallback for strings. This would
DWIM but it may not be that easy to implement or to predict, and
consistency would demand for it to return 0 on $foo?->{x} + 42 and to
return 1 on $foo?->{x} * 42, and who knows where else. Better to keep
things simple and predictable, even if it means you cannot use it in string
interpolation unless you cheat with something like "value is ${
\$foo?->{some}?->{value} }".

If we decide we don't care if it breaks existing strings, it should be
noted this construct seems pretty rare anyway: querying for "?->" on
grep.metacpan shows nothing but comments, pod and regexes.

* speaking of regexes, should /$foo?->x?->y/ or /$foo?->{x}?->{y}/ work?

grep.metacpan doesn't show any /$var?->/ constructs as they make little
sense since "?" is a metacharacter, but a few regexes have something like
/.*?->/. I think the parser should be able to tell when it's a regex
modifier or not, or when it follows a variable or not, but if this gets too
confusing or complicated it can be hidden inside a feature flag or
disallowed entirely.

* is \$foo?->x equal to (\$foo)?->x or to \($foo?->x)

The latter, just like \$foo->x is.

* should it be a CPAN module first?

As LeoNerd pointed out, XS::Parse::Infix could parse it. But I would only
give it a go if p5p felt there really is a need to make it a CPAN module
first.

* definedness vs truthfulness

Some pointed "?->" may be associated with truthfulness due to the ternary
operator "?:", whereas "//" could be more appropriate as it associates with
definedness, which is what we want. I agree that any confusion should be
avoided if possible, and that it may well be the case here. My issue with
"//->" is that "//" means defined-or, in the sense of the righthand-side
being called only if the lefthand-side is undef, which is the opposite of
what we want to achieve with "//->", and that can also lead to confusion.
So I'm not sure here. Perl uses a lot of symbols for a lot of things, and
my guess is each candidate will either be too obscure or also ambiguous
(like ~> or &->). At least with "?->" it will be familiar enough for
perlers and people coming from other languages.

Cheers!
garu

Hi there,

On Sat, 4 Jun 2022, breno wrote:

> ...
> * how would it handle things like $foo?->{x}?->{y} = 42
>
> Same as $foo->{x}{y} = 42 if defined $foo && defined $foo->{x} && defined
> $foo->{x}{y} (except way more readable)
> ...

Run that one by me again?

--

73,
Ged.

On Sat, Jun 4, 2022 at 5:13 AM breno <oainikusama@gmail.com> wrote:

breno,

First, thanks for your magnificently detailed and patient explanations. I'm
quite impressed! I've long wanted this feature for Perl and I'd be
delighted to see this feature implemented.

* definedness vs truthfulness
>
> Some pointed "?->" may be associated with truthfulness due to the ternary
> operator "?:", whereas "//" could be more appropriate as it associates with
> definedness,
>

The fact that "?" is used in several other languages for this construct is
compelling to me. More to the point, if we're going to go to YAPC (Yet
Another Punctuation Character"), at least introduce one that would read
naturally to users coming from other languages. Thus, "?->" feels both
natural and appropriate to me.

Best,
Ovid

* 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

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

Cheers,
Brett

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

--
--
oodler@cpan.org
oodler577@sdf-eu.org
SDF-EU Public Access UNIX System - http://sdfeu.org
irc.perl.org #openmp #pdl #native

On Fri, Jun 3, 2022, at 23:13, breno wrote:
> Some comments on questions that arose in the past:

First: I agree, () was more correct than undef.

> * are optional expressions evaluated? e.g. $y = $x?->{$i++}?->[++$i]
>
> I think the operator should short-circuit and not evaluate any expressions further up the chain. Like what would happen if you replaced that with a lot of &&, ternaries or if() clauses.

Agreed, as is explained by the transformative explanation:

$x?->{$i++}?->[++$i]

# equivalent, *modulo multiple-evaluation*, to

defined $x ? (defined $x->{$i++} ? $x->{*$i++*}[++$i] : ()) : ()

The multiple-evaluation waiving is tricker above, but I think it's clear if we remember that repeated $i++, which I rendered in red, evaluates to the same value as the earlier $i++, with no side effect.

> * is $foo?->{x}{y}{z} the same as $foo?->{x}?->{y}?->{z} ?
>
> No. $foo?->{x}{y}{z} means $foo?->{x}->{y}->{z}. To optional-chain everything you would have to be explicit. The reason behind this is you may want to get the original error/warning/vivification somewhere down the chain.

Agreed.

> * how would it handle things like $foo?->{x}?->{y} = 42
>
> Same as $foo->{x}{y} = 42 if defined $foo && defined $foo->{x} && defined $foo->{x}{y} (except way more readable)

Good example, should become a test.

> * will string interpolation work? e.g. "$foo?->{x} and $bar?->y()"

Well, the second one surely would not, since you can't interpolate a method call. Probably we should not have it interpolate, since the undef would be a warning anyway. We can fix this by someday adding something like template strings, where whole expressions are marked off inside the string, rather than auto-detected.

> * speaking of regexes, should /$foo?->x?->y/ or /$foo?->{x}?->{y}/ work?

/${foo}?/ already means "0 or 1 instance of the pattern in $foo", so I think making ?-> work in there is no good.

> * is \$foo?->x equal to (\$foo)?->x or to \($foo?->x)

?-> should have the same precedence as ->

> * should it be a CPAN module first?
>
> As LeoNerd pointed out, XS::Parse::Infix could parse it. But I would only give it a go if p5p felt there really is a need to make it a CPAN module first.

Hey, LeoNerd, is this an afternoon to do with XS::Parse::Infix, or a month? :)

> * definedness vs truthfulness
>
> Some pointed "?->" may be associated with truthfulness due to the ternary operator "?:", whereas "//" could be more appropriate as it associates with definedness, which is what we want. I agree that any confusion should be avoided if possible, and that it may well be the case here.

If somebody has a really great argument for something better than ?-> I am interested, but "? means truth" seems too thin, and also garu's argument about the inverted sense of // is a good one, imho.

--
rjbs

On 5/6/22 1:15, Oodler 577 via perl5-porters wrote:
> * breno <oainikusama@gmail.com> [2022-06-04 00:04:36 -0300]:
>

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


Don't forget that perl allows one to call methods on strings as in...

$class = 'Foo';
$class->new();

So, "?->" requiring a reference there would be inconsistent.

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

Op 05-06-2022 om 02:22 schreef Ricardo Signes:

> On Fri, Jun 3, 2022, at 23:13, breno wrote:
>
...

>> * speaking of regexes, should /$foo?->x?->y/ or /$foo?->{x}?->{y}/ work?
>
> /${foo}?/ already means "0 or 1 instance of the pattern in $foo", so I
> think making ?-> work in there is no good.


So having a different syntax that does work in regexes would make sense.
(But that might not be //-> either, how to parse "$x=~/$foo//->{x}/")?


HTH,

M4

On Thu, Oct 28, 2021, at 13:39, breno wrote:
> I am super excited to bring you this pre-RFC feature request, and humbly ask you to review and let me know whether it has what it takes to go further up the RFC road.

Breno,

I'm sorry, I thought I'd written this email but I don't see it. So if it's late, or if it's a duplicate, I apologize!

Could you please file this as a "full" RFC <https://github.com/Perl/RFCs/tree/main/rfcs> with the changes we've discussed? I think there are bits to hash out, but that we should get the document in place. Your original email should be a great starting point, with not too much editing required!

Thanks.

--
rjbs

On Sat, Jun 4, 2022 at 4:16 PM Oodler 577 via perl5-porters <
perl5-porters@perl.org> wrote:

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

For $foo?->{bar}?->{baz}, nothing needs to be blessed. Watering this
feature down to only supporting method dispatch would be very disappointing.

These should all be possible too:

$foo?->*
$foo?->[0]
$foo?->@*
$foo?->%*
$foo?->()

Dear porters,

RFC 0018 is already submitted as a PR: https://github.com/Perl/RFCs/pull/23

If anyone feels its content misrepresents or misses anything that needs to
be discussed before it gets accepted/rejected, please let me know. As
instructed in another thread, we should try and keep conversations here and
not on github.

Looking forward to the next steps!

Cheers,
garu

On Fri, Jun 17, 2022 at 9:59 AM Ricardo Signes <perl.p5p@rjbs.manxome.org>
wrote:

> On Thu, Oct 28, 2021, at 13:39, breno wrote:
>
> I am super excited to bring you this pre-RFC feature request, and humbly
> ask you to review and let me know whether it has what it takes to go
> further up the RFC road.
>
>
> Breno,
>
> I'm sorry, I thought I'd written this email but I don't see it. So if
> it's late, or if it's a duplicate, I apologize!
>
> Could you please file this as a "full" RFC
> <https://github.com/Perl/RFCs/tree/main/rfcs> with the changes we've
> discussed? I think there are bits to hash out, but that we should get the
> document in place. Your original email should be a great starting point,
> with not too much editing required!
>
> Thanks.
>
> --
> rjbs
>

2022-7-13 14:00 breno <oainikusama@gmail.com> wrote:

> Dear porters,
>
> RFC 0018 is already submitted as a PR:
> https://github.com/Perl/RFCs/pull/23
>
> If anyone feels its content misrepresents or misses anything that needs to
> be discussed before it gets accepted/rejected, please let me know. As
> instructed in another thread, we should try and keep conversations here and
> not on github.
>
> Looking forward to the next steps!
>
>
It looks good!

On 2022-07-12 11:09 p.m., Yuki Kimoto wrote:
> 2022-7-13 14:00 breno wrote:
> Dear porters,
>
> RFC 0018 is already submitted as a PR: https://github.com/Perl/RFCs/pull/23
>
> If anyone feels its content misrepresents or misses anything that needs to
> be discussed before it gets accepted/rejected, please let me know. As
> instructed in another thread, we should try and keep conversations here and
> not on github.
>
> Looking forward to the next steps!
>
> It looks good!

I thought so too, and earlier today had indicated such on the pull request
itself. -- Darren Duncan

On Thu, Oct 28, 2021 at 02:39:15PM -0300, breno wrote:
>
> ## Rejected Ideas
>
> I am unaware whether this feature has already been proposed for Perl 5
> in the past.
>

For completeness, I have (finally) looked in the archives for previous
proposals for the same feature. It used to be called "safe dereference"
or "safe arrow", and was discussed over a decade ago.

Here are the three threads I found:

Subject: [PATCH] Add "safe arrow/safe dereference" operator: &&->
From: David Caldwell
Date: Fri, 12 Nov 2010 20:56:43 -0800
Messages: 80, includes a patch
Link: https://www.nntp.perl.org/group/perl.perl5.porters/2010/11/msg165931.html

Subject: Semantics of safe-deref
From: Jesse Vincent
Date: Mon, 29 Nov 2010 16:26:57 -0500
Messages: 20
Link: https://www.nntp.perl.org/group/perl.perl5.porters/2010/11/msg166564.html

Subject: the old new safe dereference operator
From: Ricardo Signes
Date: Thu, 24 May 2012 21:51:16 -0400
Messages: 85
Link: https://www.nntp.perl.org/group/perl.perl5.porters/2012/05/msg187114.html

It would be worth reading them, in case some of things discussed then
were not discussed this time around. And maybe a ten years old patch can
still be somewhat useful.

--
Philippe Bruhat (BooK)

We laugh at stupidity because the alternative is to cry over it.
(Moral from Groo The Wanderer #71 (Epic))

On Sun, Jul 17, 2022 at 4:24 PM Philippe Bruhat (BooK) <book@cpan.org>
wrote:

> For completeness, I have (finally) looked in the archives for previous
> proposals for the same feature. It used to be called "safe dereference"
> or "safe arrow", and was discussed over a decade ago.
>

Hi BooK!

Yes, when I turned this pre-RFC into a proper RFC draft I did my research
and eventually uncovered those past references too. I have used them not
only to update that (and other) parts of the draft but also to include in
the FAQ many of the past arguments and design decisions made to - hopefully
- overcome them and get the proposal accepted.

https://github.com/Perl/RFCs/pull/23
https://github.com/garu/RFCs/blob/garu/optional-chaining/rfcs/rfc0018.md#rejected-ideas

Speaking of which, what are the next steps?

Thanks!
garu

On Sun, Jul 17, 2022 at 09:23:32PM +0200, Philippe Bruhat (BooK) wrote:
> On Thu, Oct 28, 2021 at 02:39:15PM -0300, breno wrote:
> >
> > ## Rejected Ideas
> >
> > I am unaware whether this feature has already been proposed for Perl 5
> > in the past.
> >
>
> For completeness, I have (finally) looked in the archives for previous
> proposals for the same feature. It used to be called "safe dereference"
> or "safe arrow", and was discussed over a decade ago.
>
> ...
>
> It would be worth reading them, in case some of things discussed then
> were not discussed this time around. And maybe a ten years old patch can
> still be somewhat useful.
>

After sending this, I felt obligated to read the 180+ emails in the
aforementioned threads.

Here are some highlights from the conversations:
* it started as &&-> and after much discussion and proposed alternatives about what the arrow
could look like, Jesse Vincent (then pumpking) settled on ?->
* a similar discussion about using a pragma happened, and reached
a similar conclusion
* the dereferencing overload operations were mentionned, and I _think_
the consensus was that there's no need to add new overload methods related
* what happens when the ?-> is part of an lvalue (and returns undef)?
* one example of autovivification in perldoc -f exists was mentionned
I expect it would "just work as expected" with ?->
* David Caldwell sent two sets of patches, I'm sure there's interesting
bits to look at in them, even if they don't apply anymore
* the ?-> (deref if defined) vs ->? (return undef if not can) came up,
this makes me thinks that once we have ?-> (topic of this RFC) and
->? (if someone writes the RFC for it), then surely we must have ?->?
* the case of the hash key pointing to undef was discussed
( $h->{foo}?->method() where the foo key does not exist vs the foo key
pointing to the value undef would behave the same)
* all the examples and counter examples in those threads would make
great test cases
* several people complained about the keyboard gymnastics needed to
type ?-> (but nobody compared that to the thing it replaces)
* being able to use the question mark (`?`) inside operators seem related
to the ?PAT? deprecation.

Names I've seen used for it:
* safe arrow
* defined dereference
* safe dereference
* maybe dereference
* safe-dereferencing arrow
* short-circuiting dereference
* conditional dereference
* defreference
* Twister™ (because of the difficult key combination needed to type it)
* undef-safe de-ref
* defined and dereference

My favorite quote from those threads, from Aristotle Pagaltzis, which I
think applies remarkably to today's post-facts trends:

> How can an opinion not founded in fact be changed by any change to
> the factual situation?

--
Philippe Bruhat (BooK)

Friendship is just brotherhood with a choice of brothers.
(Moral from Groo #9 (Image))

Hello members of the PSC!

Following up on the RFC process, I believe all feedback regarding the
Optional Chaining proposal has been properly addressed and, since nothing
new came up after what I think was a good interval, I would like the PSC to
accept this draft as exploratory.

If anyone would like to take another look at the current revised version,
you can find it at:

https://github.com/garu/RFCs/blob/garu/optional-chaining/rfcs/rfc0018.md

and the PR itself, with extra discussion, is here:

https://github.com/Perl/RFCs/pull/23

Thank you very much for your time and consideration.

Cheers!
garu


On Tue, Jul 26, 2022 at 7:15 AM Philippe Bruhat (BooK) <book@cpan.org>
wrote:

> On Sun, Jul 17, 2022 at 09:23:32PM +0200, Philippe Bruhat (BooK) wrote:
> > On Thu, Oct 28, 2021 at 02:39:15PM -0300, breno wrote:
> > >
> > > ## Rejected Ideas
> > >
> > > I am unaware whether this feature has already been proposed for Perl 5
> > > in the past.
> > >
> >
> > For completeness, I have (finally) looked in the archives for previous
> > proposals for the same feature. It used to be called "safe dereference"
> > or "safe arrow", and was discussed over a decade ago.
> >
> > ...
> >
> > It would be worth reading them, in case some of things discussed then
> > were not discussed this time around. And maybe a ten years old patch can
> > still be somewhat useful.
> >
>
> After sending this, I felt obligated to read the 180+ emails in the
> aforementioned threads.
>
> Here are some highlights from the conversations:
> * it started as &&-> and after much discussion and proposed alternatives
> about what the arrow
> could look like, Jesse Vincent (then pumpking) settled on ?->
> * a similar discussion about using a pragma happened, and reached
> a similar conclusion
> * the dereferencing overload operations were mentionned, and I _think_
> the consensus was that there's no need to add new overload methods
> related
> * what happens when the ?-> is part of an lvalue (and returns undef)?
> * one example of autovivification in perldoc -f exists was mentionned
> I expect it would "just work as expected" with ?->
> * David Caldwell sent two sets of patches, I'm sure there's interesting
> bits to look at in them, even if they don't apply anymore
> * the ?-> (deref if defined) vs ->? (return undef if not can) came up,
> this makes me thinks that once we have ?-> (topic of this RFC) and
> ->? (if someone writes the RFC for it), then surely we must have ?->?
> * the case of the hash key pointing to undef was discussed
> ( $h->{foo}?->method() where the foo key does not exist vs the foo key
> pointing to the value undef would behave the same)
> * all the examples and counter examples in those threads would make
> great test cases
> * several people complained about the keyboard gymnastics needed to
> type ?-> (but nobody compared that to the thing it replaces)
> * being able to use the question mark (`?`) inside operators seem related
> to the ?PAT? deprecation.
>
> Names I've seen used for it:
> * safe arrow
> * defined dereference
> * safe dereference
> * maybe dereference
> * safe-dereferencing arrow
> * short-circuiting dereference
> * conditional dereference
> * defreference
> * Twister™ (because of the difficult key combination needed to type it)
> * undef-safe de-ref
> * defined and dereference
>
> My favorite quote from those threads, from Aristotle Pagaltzis, which I
> think applies remarkably to today's post-facts trends:
>
> > How can an opinion not founded in fact be changed by any change to
> > the factual situation?
>
> --
> Philippe Bruhat (BooK)
>
> Friendship is just brotherhood with a choice of brothers.
> (Moral from Groo #9
> (Image))
>