request: `exists(File | Directory)` STDLIB function

[a-frantz]

I want to do something like this:

    output {
        Array[String] labels = if exists("labels.txt") then read_lines("labels.txt") else []
    }

but am currently writing an ugly workaround to achieve the same logic.

[rhpvorderman]

command <<<
my_commad

if [ ! -f "labels.txt" ] 
then touch labels.txt  # Labels.txt will be empty.
fi

>>>
output
Array[String] labels = read_lines("labels.txt")

Alternatively if the existance of the file is dependent on the inputs you could use those rather than checking for the existence of the file.

[patmagee]

I can also see a separate use case for this which the spec (or maybe engines) handles poorly currently. If I run a workflow with a File type (note not File?) most engines will not assert that the file actually exists until it goes to try and use that file.

so you could have exists('...') used in the workflow body itself.

[claymcleod]

To me, it seems like there is at least one, if not two, bona fide use case(s) here where one would ideally be able to avoid the overhead of a task to use the existing standard library functions. This is also relatively simple and, to my eye, seems to be a lower bar for existing that some of the already implemented standard library functions. Given these things, I'm inclined to include it in WDL 1.4. Let me know what folks thoughts are on that.

[claymcleod]

It occurs to me that, in 1.2.1 and 1.3, we clarified that File and Directorys must exist at evaluation time. So this technically possible today by trying to create a File? or Directory? and checking if the value is defined(). That being said, it doesn't feel natural to think that way, so perhaps this just needs to take a String argument that points to the path.

[patmagee]

I feel like exists(..) is just a syntactic wrapper around:

exists(testval){
  File? foo = testval
  return defined(foo)
}

[claymcleod]

I think the conditional-output use case is sufficient for 1.4, but the useful signature is Boolean exists(String), not exists(File|Directory): a File or Directory value has already passed existence validation. The function should use the normal path-resolution rules for its evaluation context, return false only when the path is absent, return true for either a file or directory, and preserve errors for inaccessible or unresolvable paths. Would anyone object to narrowing the proposal to those semantics?