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

Re: Pre-RFC: Optional Chaining

Thread Previous | Thread Next
June 4, 2022 03:13
Re: Pre-RFC: Optional Chaining
Message ID:
On Fri, Jun 3, 2022 at 5:38 PM Ricardo Signes <>

> 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. ?=~, ?=,

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

* 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

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


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