wdl icon indicating copy to clipboard operation
wdl copied to clipboard

Enable all expressions to operate on optional values within interpolations

Open jdidion opened this issue 2 years ago • 3 comments

The section on Concatenation of Optional Values currently (as of 1.1) says:

"Within expression placeholders the string concatenation operator (+) gains the ability to operate on optional values, to facilitate formulation of command-line flags. When applied to two non-optional operands, the result is a non-optional String. However, if either operand has an optional type, then the concatenation has type String?, and the runtime result is None if either operand is None (which is then replaced with the empty string)."

I propose generalizing this to all expressions and updating the language to something like:

"within an interpolation, any expression that operates on a non-optional value may operate on an optional value; if the optional value is None, the expression is replaced with None, otherwise the optional value is cast to a non-optional value."

jdidion avatar Nov 09 '21 17:11 jdidion

So is the suggestion that if one value of an expression evaluates to None, then the whole expression evaluates to None?

patmagee avatar Nov 23 '21 13:11 patmagee

I think that will be functionally true in most cases. But the specific suggestion is for any given operation or function call within an interpolation, if an optional value is passed as one of the arguments where a non-optional value would typically be required, either replace the operation/call with None if the value is None, or cast the optional value to non-optional and proceed as usual. This would cascade.

So in the following example the first interpolation expression would evaluate to None (and thus result in the empty string) but the second would not:

Int? foo = None
String s1 = "~{sep('-', [1, 2 + foo, 3])}"  # ""
String s2 = "~{sep('-', select_all([1, 2 + foo, 3]))}"  # "1-3"

jdidion avatar Nov 23 '21 18:11 jdidion

Maybe this is too lenient and will lead to hard-to-catch errors. But I'm not sure if it's any more dangerous than our current allowance for None in string concatenation.

jdidion avatar Nov 23 '21 18:11 jdidion