XPath "otherwise" operator

[michaelhkay]

The draft specification proposes an "otherwise" operator. This issue seeks WG endorsement of this addition.

See section 4.18 of the XPath draft specification.

The semantics are that (X otherwise Y) returns X, except in the case where X evaluates to an empty sequence, in which case it returns Y. A typical usage would be //employee ! (@location otherwise "Denver").

There are two questions the WG might choose to discuss:

• How should the operator be spelled? The symbol "?:" has been proposed as an alternative to the keyword "otherwise".
• What should the operator precedence be?

I propose that once approved, we also add this operator to the list recognised by the fn:op function.

[ChristianGruen]

• otherwise sounds like an intuitive choice. ?: may be known from some other programming languages (the most popular being Kotlin), but the XML community may be better acquainted with the use of keywords.
• The precedence seems well-chosen. I think the operator should have a higher precedence than arithmetic expressions and a lower precedence than the Unary expression, which is currently the case.

[ndw]

👍 for otherwise.

[benibela]

I have already implemented it with the otherwise name and am using it in production....

[michaelhkay]

There was discussion of whether (a) people might think the test on the LHS was testing the EBV of false(), rather than being an empty sequence, or (b) whether in fact that might be a more useful definition.

[ChristianGruen]

Many languages have an analogous solution for otherwise, it’s often called null coalescing operator: https://en.wikipedia.org/wiki/Null_coalescing_operator

A few languages also have a dedicated operator for boolean checks, sometimes called elvis operator. There’s a Wiki page for that as well (https://en.wikipedia.org/wiki/Elvis_operator), but it’s misleading, as many of the examples are actually existence checks.

[cmsmcq]

In the discussion, one argument was that shifting to the effective boolean value was over-generalizing a proposal that solves one specific problem, and effective boolean values will just confuse the issue (and possibly users).

My reason for finding that argument non-conclusive is that a keyword like otherwise does suggest the last branch of a conditional (not just to XSLT programmers), and leaves unspecified what the condition was. The two possibilities we seem to be canvassing appear to be that ( F otherwise G ) means either (if ( F ) then F else G ) or (if (exists( F )) then F else G ). The ordinary-language association of otherwise with conditions of all kinds seems to me to suggest that the former expansion will feel more intuitive to many users.

If we do want the semantics of the latter expansion, I think the suggestion of changing the keyword to fallback or some other word may be a good one. Fallback works well for me, if we are sure we won't want it as a keyword for some other construct.

[Arithmeticus]

I hesitate to support this proposal because "otherwise" has implications of being part of an if...then... construction, and could be understandably misinterpreted as the : in a ternary operation. We are trying to provide a fallback condition for null, a replacement for (x, y)[1] (expressed in C# as ??).

I recommend a different keyword. Some suggestions

• fallback
• ifempty
• ifnull
• whenempty
• whennull
• onempty
• onnull

[ChristianGruen]

I initially proposed ?:, which is used by Kotlin, Objective-C and CFML. It’s also used/known as elvis operator, though.

I like otherwise a lot, but another alternative could be default (I’m no native speaker, though).

[dnovatchev]

I hesitate to support this proposal because "otherwise" has implications of being part of an if...then... construction, and could be understandably misinterpreted as the : in a ternary operation. We are trying to provide a fallback condition for null, a replacement for (x, y)[1] (expressed in C# as ??).

I recommend a different keyword. Some suggestions

• fallback
• ifempty
• ifnull
• whenempty
• whennull
• onempty
• onnull

I think that onnull is the most clear and unambiguous of them all.

I tried to find good synonyms for "coalesce", "backup", "alternately", and "surrogate", but "onnull" seems better.

I think that the meaning of this construct is to act as a "sentinel" and would also support something based or close to this word, maybe "guard as".

[michaelhkay]

I'd be OK with on-empty, though I prefer otherwise: it reads well and you get accustomed to it very quickly. An empty sequence isn't "null" so that seems a very poor choice. "Fallback" sounds to me more like what you do when there's an error. "Alternately" means "every second time" (perhaps you intended "alternatively"), "surrogate" smells of Unicode, "coalesce" suggests you combine the two operands, "backup" means you revert to some previous state.

on-empty will probably be assumed by some users to trigger on a zero-length string. You can never capture the entire semantics of a function or operator in its name.

[ndw]

There will be many users who have no idea what "null" means. The only explicit mention of null that I see in the F&O spec currently is related to JSON null values which isn't what we mean here.

I could live with the x-empty variants, but I also prefer otherwise.

[michaelhkay]

The proposal was accepted on 2022-12-21.