[FEATURE INCUBATOR] Add shorthand notations for required and multiple

[rcannood]

Feature summary

While looking at a simple CWL workflow I found it quite interesting that CWL has a different way of specifying input/output types.

Example Viash:

arguments:
  - name: --multiple_input
    type: file
    required: true
    multiple: true
  - name: --optional_string
    type: string
    required: false
  - name: --optional_multiple_integer
    type: integer
    multiple: true

CWL:

inputs: 
    Multiple_input:
        type: File[]
        inputBinding:
            prefix: --multiple_input
    Optional_string:
        type: string?
        inputBinding:
            prefix: --optional_string
    Optional_multiple_integer:
        type: int[]?
        inputBinding:
            prefix: --optional_multiple_integer

Feature description

I'd like to pitch adding type: file[], type: file? and type: file[]? as sugar syntax for:

• file[]: {type: file, multiple: true, required: true}
• file?: {type: file, multiple: false, required: false}
• file[]?: {type: file, multiple: true, required: false}
• file: {type: file, multiple: false, required: true}

Ohno. This is a breaking change! (because right now the default value for required is false)

:(

If we don't want to make it a breaking change, we could consider:

• file: {type: file, multiple: false, required: false}
• file[]: {type: file, multiple: true, required: false}
• file!: {type: file, multiple: false, required: true}
• file[]!: {type: file, multiple: true, required: true}

Though I really don't like this notation since it's not a commonly used/understood notation/syntax

Why is this feature beneficial?

To me, it feels like a much easier way to show what the data type of the par object will be inside the script. It makes it easier to talk about an argument, because now in conversations I will sometimes talk about "an optional multiple file argument", but "a file[]? argument" would be easier.

Hendrik mentioned that he had some concerns introducing unnecessary sugar syntax, which I totally understand.

Alternatives considered

No response

Possible solution

No response

Confirmation

• I have searched the existing issues to make sure this is not a duplicate request.
• I have provided clear and concise information about the feature.

[Grifs]

because now in conversations I will sometimes talk about "an optional multiple file argument", but "a file[]? argument" would be easier.

unless you're talking, because in that logic, one should say "a file open square bracket close square bracket question mark argument" ... or mentally & verbally translate it to "an optional multiple file argument". So not much easier 😛