ALF11 — Alf should have a "null coalescing" operator

By default, the multiplicity of a parameter in UML is 1..1, indicating that a value is required for that parameter. A call action for an activity or operation with such a mandatory parameter will not fire unless a value is provided for that parameter. Since Alf behavior and operation invocation expressions map to call actions, if an argument for a mandatory parameter evaluates to null, the behavior or operation will simply not be called, and the entire expression then evaluates to null. This is usually unexpected behavior.

Alf rules currently allow an expression with multiplicity lower bound of 0 to be used as an argument for a parameter with multiplicity lower bound greater than 0. This is because it is often the case that an expression that statically has multiplicity lower bound of 0 is really known at run time to be non-null. For example, the expression a != null? a: 1, presuming a is a local name, is statically determined to have multiplicity lower bound of 0 (because that is the lower bound of the second operand a). Dynamically, however, the expression will never really evaluate to null.

It would be useful for Alf to have a specific operator that checks a value for null and, if it is null, provides an alternate value for it. Such an operator exists in a number of current programming languages, and is generically known as a "null coalescing" operator. The symbol "??" is used for this operator in, e.g., C#, Swift and PHP. With such an operator, the example above would be notated a??1, which could be easily given a static multiplicity lower bound of 1 (that of the second operand 1), without having to do any fancy analysis of conditional expressions and possible paths.

If such an operator existed in Alf, it would then also be possible to strengthen the rule for argument multiplicity to invalidate the use of a possibly null argument for a mandatory operation, since the null coalescing operator could always be used to provide a non-null argument. This would prevent the kind of non-intuitive invocation behavior described at the outset.

Add a null-coalesing operator

As discussed in issued ALF11-77, introduction of a null-coalescing operator is not absolutely necessary for resolving the problem identified in this issue. Nevertheless, presuming the tightening of multiplicity conformance rules proposed in the resolution to ALF11-77, it would still often be useful to have a null-coalescing operator.

Further, given the adoption of multiplicity and type tracking, as also proposed in the resolution to ALF11-77, it would not be necessary require the inclusion of null-coalescing expressions at the Alf minimum conformance level. If, on the other hand, null-coalescing expressions were to be adopted along with the tighter multiplicity rules, but multiplicity and type tracking were not adopted, then it would be necessary to include null-coalescing expressions at the minimum conformance level, because, otherwise, there would be no way to get around the multiplicity checks by dynamically checking for null. And this would be a problem, since Java syntax does not include a null-coalescing operator, and Alf minimum conformance is suppose to reflect a common syntax with Java.