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

Re: Pre-RFC: Optional Chaining

Thread Previous | Thread Next
Ricardo Signes
June 5, 2022 00:22
Re: Pre-RFC: Optional Chaining
Message ID:
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:


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


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

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