Perl adds logical exclusive-or at expression precedence

Perl already has a logical exclusive-or operator. The reason to add ^^ in 5.39.9 is where it sits in an expression. Existing xor belongs to the low-precedence group used alongside and and or. The new spelling gives exclusive-or a place among the symbolic logical operators, so an assignment can receive its result without additional grouping.

Paul Evans released the snapshot on 20 March, as recorded in the Perl release history. The 5.39.9 release notes describe the addition as completing the medium-precedence logical set. That is a small language change with a concrete effect on how a familiar condition can be written.

I still reach for Perl when a text transformation can fit into a short expression. In that setting, precedence is a practical part of readability. A compact program becomes less useful when a reader has to reconstruct which operation receives the result of another.

The boolean operation was already available

Exclusive-or is true when exactly one of its operands is true. If both are true, or both are false, the result is false. The new operator does not add a new truth condition to Perl. It supplies another grammatical position for expressing it.

The operator documentation in the release places ^^ on the same precedence row as || and //. That row associates to the left. && binds more tightly, while assignment binds less tightly. The word xor sits below assignment, alongside or.

An illustrative choice between two already-computed flags shows how assignment groups with the new token. The value stored in the result describes whether exactly one input condition is true.

use strict;
use warnings;

my $from_file = 1;
my $from_stdin = 0;
my $exactly_one = $from_file ^^ $from_stdin;

print $exactly_one ? "one source\n" : "invalid choice\n";

The assignment receives the logical result. With the word operator, an equivalent expression needs explicit grouping around the exclusive-or operation to ensure the assignment stores the result of comparing both conditions.

my $exactly_one = ($from_file xor $from_stdin);

Without those parentheses, assignment takes place before xor because assignment has higher precedence. That is the substantive difference behind the additional punctuation. An operator can express the intended boolean relation and still group incorrectly for the surrounding statement.

The same reasoning explains why a mechanical replacement across a program would be inappropriate. Existing xor expressions may depend on their low precedence. A new spelling is useful where expression precedence matches the intended grouping. It does not establish that the old spelling has become incorrect.

Both operands have to be evaluated

The documentation states that ^^ evaluates both operands. This follows the information required by exclusive-or. Knowing that the left operand is true does not establish the result, because a true right operand would make the result false. Knowing that the left operand is false also does not establish the result, because the right operand then determines it.

That makes this operator different from the familiar conditional evaluation of && and ||. A function call on the right of ^^ still runs when the left-hand result is already known. The symmetric appearance of the symbols does not imply symmetric control-flow behaviour across all the operators.

For an expression involving side effects, this evaluation rule belongs in the design of the statement. A predicate that reads external state or changes a value will run on both sides. When the purpose is to validate two values that are already available, that is usually straightforward. When the purpose is to conditionally perform work, exclusive-or does not supply the conditional execution that a reader might associate with adjacent symbolic operators.

This is also why a truth table alone is an incomplete explanation of the change. It describes the result after both truth values are available. It does not describe what the interpreter must evaluate to obtain them. The operator documentation makes both parts explicit.

Logical xor differs from bitwise xor

The release notes distinguish the logical operators from the existing bitwise spellings, including ^. Replacing ^^ with ^ would change the operation. Logical exclusive-or asks about the truth values of its operands. Bitwise exclusive-or operates at a different level.

That distinction matters when values encode flags but are not themselves restricted to a single boolean representation. The correct operator follows the question being asked. A choice between two conditions needs a logical operation, while a calculation on bit patterns has a different purpose. The new token makes the logical intention available without moving the expression into the low-precedence word-operator group.

I regard that as a useful addition to an established language. The change addresses a specific inconsistency in expression construction without requiring a new abstraction or module. Its value is clearest in code that already needs exclusive-or and otherwise requires parentheses to place the result correctly.

The development snapshot also removes a noisy warning

The same release removes the warning about a lexical subroutine masking a previously declared package subroutine. The notes say the warning had appeared in 5.39.7, was inconsistent with lexical-variable behaviour and produced unnecessary warnings across CPAN modules. This is a separate change, but it gives the snapshot context beyond the new token.

Development feedback can lead to removing a diagnostic as well as adding syntax. A warning needs to identify something useful to its recipient. In this case, the release notes explain why the implementation's earlier choice did not meet that requirement. Module authors examining 5.39.9 can distinguish the deliberate warning removal from a missed diagnostic while also checking expressions that use the newly available exclusive-or spelling.