The following coercions are missing from the table:
Target Type | Source Type | Notes/Constraints |
---|---|---|
Array[Y] |
Array[X]+ |
X must be coercible to Y |
In the Type Coercion section, coercion from String
to any other type (except File
) is not allowed. However, in Appendix A it is stated that
read_lines()
will return anArray[String]
where each element in the array is a line in the file. This return value can be auto converted to otherArray
values.
Because there is currently no alternative method to convert String
to non-String
values, the coercion of read_lines
return value is allowed as a special case.
However, in this situation, it is strongly recommended to instead use a JSON file containing an array. For example, if you want to read an array of integers into an Array[Int]
, the file would look like:
ints.json
[1, 2, 3]
And the WDL would be:
Array[Int] ints = read_json("ints.json")
The example for main.wdl
incorrectly uses workflow output syntax that was deprecated in Draft-2 and removed in 1.0. It should be:
import "other.wdl" as other
task test {
input {
String my_var
}
command <<<
./script ~{my_var}
>>>
output {
File results = stdout()
}
runtime {
container: "my_image:latest"
}
}
workflow wf {
Array[String] arr = ["a", "b", "c"]
call test
call test as test2
call other.foobar
call other.other_workflow
call other.other_workflow as other_workflow2
output {
File test_results = test.results
File foobar_results = foobar.results
}
scatter(x in arr) {
call test as scattered_test {
input: my_var = x
}
}
}
The following sub-sections are missing from the Type Coercions section of the spec.
During string interpolation, there are some operators for which it is possible to coerce the same arguments in multiple different ways. For such operators, it is necessary to define the order of preference so that a single function prototype can be selected from among the available options for any given set of arguments.
The +
operator is overloaded for both numeric addition and String concatenation. This can lead to the following kinds of situations:
String s = "1.0"
Float f = 2.0
String x = "${s + f}"
There are two possible ways to evaluate the s + f
expression:
- Coerce
s
toFloat
and perform floating point addition, then coerce toString
with the result beingx = "3.0"
. - Coerce
f
toString
and perform string concatenation with result beingx = "1.02.0"
.
Similarly, the equality/inequality operators can be applied to any primitive type.
The order of preference is:
Int
,Float
:Int
coerces toFloat
X
,Y
: For any primitive typesX
!=Y
, both are coerced toString
- If applying
+
to two values of the same type that cannot otherwise be summed/concatenated (i.e.Boolean
,File
,Directory
), both values are first coerced toString
Implementers may choose to allow limited exceptions to the above rules, with the understanding that workflows depending on these exceptions may not be portable. These exceptions are provided for backward-compatibility, are considered deprecated, and will be removed in a future version of WDL.
Float
toInt
, when the coercion can be performed with no loss of precision, e.g.1.0 -> 1
.String
toInt
/Float
, when the coercion can be performed with no loss of precision.X?
may be coerced toX
, and an error is raised if the value is undefined.Array[X]
toArray[X]+
, when the array is non-empty (an error is raised otherwise).Map[W, X]
toArray[Pair[Y, Z]]
, in the case whereW
is coercible toY
andX
is coercible toZ
.Array[Pair[W, X]]
toMap[Y, Z]
, in the case whereW
is coercible toY
andX
is coercible toZ
.Map
toObject
, in the case ofMap[String, X]
.Map
to struct, in the case ofMap[String, X]
where all members of the struct have typeX
.Object
toMap[String, X]
, in the case where all object values are of the same type.