Default values for process inputs

[bentsherman]

Implements default values for process inputs as requested in #3507

While we could merge this feature as is, I'd like to try to implement optional and named inputs as well, to make sure that they are designed to work together properly.

[pditommaso]

This is a good start. If I understand it correctly it works at the level of the process composition ie if the argument is provided matches the ones expected.

But I think there are use cases in which the argument is provided, but the associated channel brings no value (or null).

A classic example may be this

[bentsherman]

I think the case of a null value could be handled with a separate nullable option as discussed here.

If the channel is empty, then the user can use ifEmpty() to provide a default value. We could have Nextflow do this automatically if a default value is defined in the process, but I don't know if that is always desirable. It might cause a process to be executed when the user didn't want it. I have to think about this one more.

[fabianegli]

In #3714 it is noted that

The main caveat is that inputs with default values should be declared after inputs with no default, otherwise it's useless.

Is that really a necessary constraint to have? And what does "useless" actually mean on a technical level? It is not quite clear to me from reading through this and the other issue.

[bentsherman]

@fabianegli see the docs example I added in this PR for a more detailed explanation. If your process declares an input B with no default value, after an input A with a default value, then you will always have to give a value for A when you call the process, because B comes after A. Thus the default value for A is useless because it can never be used.

I think the caveat effectively goes away if combined with named inputs, because then you can specify the inputs in any order when you call the process.

[fabianegli]

I understand the restriction an I am wondering what purpose it might serve. And my point is that I can't think of any situation I'd actually want it. If the defaults are introduced with named inputs, which removes this restriction I see this as something which might surprise some pipeline/module devs rather than a problem.

[bentsherman]

And my point is that I can't think of any situation I'd actually want it.

Not sure what you mean. It's not an artificial restriction that we impose, it's a natural consequence of how arguments are passed in a function call. Most languages that support default values in function calls have this same limitation -- C++, Java, Python, etc.

Also, I guess I should say that named arguments don't "remove" the restriction so much as they provide a workaround by allowing you to order arguments however you like.

[fabianegli]

My questioning was aimed to find out wether this behaviour is desirable in this case - irrespective of wether it is introduced intentionally or not. The fact that it is prevalent in other languages seems to hint at it being sensible for some reasons that I am missing. As you say, in some cases it would allow a more organized workflows/processes definition by grouping related inputs independently of wether they have defaults or not. Because the named arguments already make arbitrary input orderings possible, I am not convinced that the effort to remove the order constraint would be worthwhile.

[bentsherman]

Gonna fold this one into #4553 doing something like this:

process foo {
  input:
    List<Path> inputs
    String args = '--default-option'
  output:
    stdout
  script:
    """
    foo_cmd ${args} ${inputs}
    """
}

workflow {
  foo( file('*.foo') )
}