Clarifying "Absence of presence" and "presence of absence" (optional -> non optional task input with default)

Essentially, if I have some workflow and task that connections an optional value to a non-optional value. This should be a validation failure right?

workflow SmallWorkflow {
  input {
    String? myString
  }
  call Print {
    input:
      inp=myString
  }
}

task Print {
  input {
    String inp = "default"
  }
  command <<<
    echo '{inp}'
  >>>
  output {
    String out = read_string(stdout())
  }
}

How about if you slightly change the workflow to have:

task Print {
  input {
    String? inp = "default"
  }
  #...
}

My interpretation is:

• providing a value that is null => value becomes null
• not providing a value (ie, it’s not present in the input: map => default is applied

But I don’t think the spec clarifies this, and looks like there is ambiguity in Cromwell and MiniWDL.

Edit: I believe the way to apply a default in a task is to do:

task Print {
  input {
    String? inp
    String _inp = select_first([inp, "default"])
  }
  #...
}

[mlin]

miniwdl has a command-line flag --no-quant-check that relaxes some of the static checks and would probably make this pass validation.

However, I’m not certain whether it would then exhibit the same runtime behavior as Cromwell. In particular, if task Print receives an explicit binding of inp to None, miniwdl would consider that a runtime error since its type is not optional; but another interpretation might use the default value in that case.

By analogy, consider this python function

def f(x=1):
  return x

f() == 1 but f(x=None) == None. “Absence of presence” isn’t the same as “presence of absence” (in python)

[pshapiro4broad]

I tried out your example, after adding version 1.0 and fixing a typo. miniwdl check rejects it (correctly), cromwell allows it (incorrectly). To me this looks like a bug in cromwell. It looks like the presence of a default value is affecting the type cromwell creates for the task input.