The Need

There has already been some discussion about safe dereferencing. We have even had a poll on what an operator for that should look like. Safe dereferencing means dereferencing in a way that neither auto-vivificates undefined values nor chokes over attempts to call methods of undefined objects. Safe dereferencing is a way to carry undefinedness through certain expressions with less clutter than using explicit conditionals.

Examples:

  $name = $user[$idx]  -> {'name'};     # may create a hash
  $name = $user[$idx] ?-> {'name'};     # leaves @user alone
  $name = $person  -> name;             # chokes on undef
  $name = $person ?-> name;             # passes undef on
[download]

Note that the question-marked arrow here stands in for whatever symbol would have been chosen. I don't care.

The Generalization

I can see a more general concept behind the cases the safe dereferencing operator was meant to address. What if we had a way to safely bail out of all sorts of expressions upon a check for undefinedness? The situation where we want to perform safe dereferencing would be one possible occasion for this. Others could be arithmetic expressions or string manipulations, you name it. And bailing out here does not only mean carrying on with a value of undef, but actually cutting useless branches short, like boolean operators do.

The Details

I will call our new operator lightning-rod for reasons I'll elaborate on in a moment. It is a unary postfix operator like the postfix variant of the auto-increment operator ++, which also shares its precedence level and some aspects of its visual appearance.

I am suggesting the symbol ^^ for this operator.

Its high precedence makes sure it attaches to a single term in a numerical, string or binary expression. As a unary operator it does not grab other terms to use as arguments. Being well-behaved if somewhat boring, it does not change its argument. It just checks whether the argument is defined.

If so, the expression is evaluated like if the lightning rod wasn't there. If not, lightning strikes, hits the rod, and is safely grounded, where ground level means the precedence level of || and //. The effect is that the whole expression short-cuts to undef, unless it is an or-chain or some combination of parts of even lower precedence, in which case just the subexpression short-cuts.

Examples:

 
# If velocity is defined, use it, otherwise don't.
# Note that just the concatenation arg is guarded,
# so you still get an error if $b is not a hashref.

$a = $b->{'velocity'}^^ . ' mph' // 'unknown';

# Safe dereferencing of $d (it may be undefined).
# Note that the second dereference is normal,
# so parent() returning undef would trigger an error.

$c = $d^^ ->  parent  ->  name;

# Safe dereferencing of $d (it may be undefined).
# Note that the second dereference is normal,
# so a nonexistent 'parent' component would be created.

$c = $d^^ ->{'parent'}->{'name'};
[download]

Notes

It is important to grasp the precedence level of short-cuts introduced by the lightning-rod operator. In particular, short-cuts won't escape out of parentheses or across commas. So, e.g., you can't cut a function call from within the argument list, say.

# these two are equivalent:
$a = foobar($b^^);
$a = foobar($b);

# this would be safer:
$a = defined($b)? foobar($b): undef;
[download]

If you do want to get out of some nested structure, you might have to wire more than one short-cut:

$f = ($g | $h^^ | $i)^^ & $j;
[download]

I am aware that the other postfix operators, ++ and --, all have prefix variants, too. While it would be conceivable to make prefix ^^ legal and act like postfix ^^, it does not strike me as equally intuitive. Therefore I lean on sticking just with postfix. But I don't have a strong opinion either way.

A lightning-rod at the very end of an expression is more than a no-op. As it short-cuts out to the boolean-or level it may well guard against medium preference operations on undef such as numerical or string operations.

# these two are equivalent:
$a =              $b . $c^^;
$a = defined($c)? $b . $c: undef;
[download]

The defined-and operator has also been suggested as a definedness-aware operator in the past. Defined-and can more easily be emulated using existing operators than either the lightning-rod or defined-or.

# these two are equivalent:
$a =         foo() ?? bar();
$a = defined(foo())?  bar(): undef;
[download]

Note that the double question mark here stands in for whatever symbol would have been chosen for defined-and.

Inside quoted strings, carets as well as lightning-rods should not have new special meanings. To guard against undef being expanded into a string, take it outside the quotes and stick a lightning-rod next to it:

$a = "hello $b";       # may trigger a warning
$a = "hello $b^^";     # does not help
$a = 'hello ' . $b^^;  # may evaluate to undef
[download]

While auto-increment and auto-decrement can only be applied to modifyable values (L-values), lightning-rod can adorn anything. Applied to an L-value, however, the result is no longer modifyable:

$a = $b^^++;        # error
$a = $b++^^ * $c;   # ok
$a = ++$b^^ * $c;   # ok but pointless
[download]

At least this is the behaviour I figure to be easiest to implement. I wouldn't mind making the first case legal, though. It would increment $b only if it was defined.

Maybe someone was hoping the double caret would some day be used for a medium-level precedence version of xor. Pardon me. I think that would be just as strange to C or bash programmers while much less useful to us.

In fact, since lightning-rod is a postfix operator, it would not completely rule out another infix operator using the same symbol, although I wouldn't want to consider that. Look at it this way: Being a postfix operator, it will not easily be mistaken for the other thing we don't want to talk about.

If you like the operator but not how I named it, I could also settle on "bat operator". A bat hangs somewhere beneath the ceiling and can grab something that is not too heavy for it to lift, and put that down elsewhere. Should we talk about a wumpus operator next? ☺

A more conservative name for ^^ might be "definedness guard".

Staying in the metaphor of electrical safety, the name "fuse operator" also has a nice ring to it. It would make a conveniently short token name, too.

The Conclusion

The defined-or operator // introduced in Perl v5.10 gave us a very useful option for short-cutting on definedness. It makes Perl expressions a tad more expressive. Expanding on this notion, I am now presenting a candidate for a fine companion. It would be more than a replacement for the safe dereferencing operator that seems to be so hard to agree upon.

Of course it will take some getting used to. And a proof that it can be implemented efficiently has yet to be given. I might look into that if there is sufficiently encouraging feedback while nobody else volunteers.

Update 1: typo (thanks, MidLifeXis)
Update 2: another name: fuse