Typed processes

docs/index.md

@@ -77,6 +77,7 @@ reports
 script
 working-with-files
 process
+process-typed
 channel
 workflow
 module
@@ -174,6 +175,7 @@ developer/packages
 tutorials/rnaseq-nf
 tutorials/data-lineage
 tutorials/workflow-outputs
+tutorials/static-types
 tutorials/metrics
 tutorials/flux
 ```

docs/migrations/25-10.md

@@ -16,16 +16,16 @@ The `params` block is a new way to declare pipeline parameters in a Nextflow scr
 
 ```nextflow
 params {
-  // Path to input data.
-  input: Path
+    // Path to input data.
+    input: Path
 
-  // Whether to save intermediate files.
-  save_intermeds: Boolean = false
+    // Whether to save intermediate files.
+    save_intermeds: Boolean = false
 }
 
 workflow {
-  println "params.input = ${params.input}"
-  println "params.save_intermeds = ${params.save_intermeds}"
+    println "params.input = ${params.input}"
+    println "params.save_intermeds = ${params.save_intermeds}"
 }
 ```
 
@@ -39,34 +39,73 @@ Type annotations are a way to denote the *type* of a variable. They help documen
 
 ```nextflow
 workflow RNASEQ {
-  take:
-  reads: Channel<Path>
-  index: Value<Path>
+    take:
+    reads: Channel<Path>
+    index: Value<Path>
 
-  main:
-  samples_ch = QUANT( reads, index )
+    main:
+    samples_ch = QUANT( reads, index )
 
-  emit:
-  samples: Channel<Path> = samples_ch
+    emit:
+    samples: Channel<Path> = samples_ch
 }
 
 def isSraId(id: String) -> Boolean {
-  return id.startsWith('SRA')
+    return id.startsWith('SRA')
+}
+
+// feature flag required for typed processes
+nextflow.preview.types = true
+
+process fastqc {
+    input:
+    (id, fastq_1, fastq_2): Tuple<String,Path,Path>
+
+    output:
+    logs = tuple(id, file('fastqc_logs'))
+
+    script:
+    """
+    mkdir fastqc_logs
+    fastqc -o fastqc_logs -f fastq -q ${fastq_1} ${fastq_2}
+    """
 }
 ```
 
 The following declarations can be annotated with types:
 
 - Pipeline parameters (the `params` block)
 - Workflow takes and emits
+- Process inputs and outputs
 - Function parameters and returns
 - Local variables
 - Closure parameters
 - Workflow outputs (the `output` block)
 
 Type annotations can refer to any of the {ref}`standard types <stdlib-types>`.
 
-Type annotations can be appended with `?` to denote that the value can be `null`:
+Some types use *generic type parameters* to work with different data types in a type-safe way. For example:
+
+- `List<E>` and `Channel<E>` use the generic type `E` to specify the element type in the list or channel
+- `Map<K,V>` uses the generic types `K` for the key type and `V` for the value type in the map
+
+The following examples show types with type parameters:
+
+```nextflow
+// List<E> where E is String
+def sequences: List<String> = ['ATCG', 'GCTA', 'TTAG']
+
+// List<E> where E is Path  
+def fastqs: List<Path> = [file('sample1.fastq'), file('sample2.fastq')]
+
+// Map<K,V> where K is String and V is Integer
+def readCounts: Map<String,Integer> = [sample1: 1000, sample2: 1500]
+
+// Channel<E> where E is Path
+def ch_bams: Channel<Path> = channel.fromPath('*.bam')
+```
+
+Type annotations can be appended with `?` to denote values can be `null`:
 
 ```nextflow
 def x_opt: String? = null
@@ -78,6 +117,8 @@ In the type system, queue channels are represented as `Channel`, while value cha
 Nextflow supports Groovy-style type annotations using the `<type> <name>` syntax, but this approach is deprecated in {ref}`strict syntax <strict-syntax-page>`. While Groovy-style annotations remain valid for functions and local variables, the language server and `nextflow lint` automatically convert them to Nextflow-style annotations during code formatting.
 :::
 
+See {ref}`migrating-static-types` for details.
+
 ## Enhancements
 
 <h3>Nextflow plugin registry</h3>
@@ -113,7 +154,7 @@ workflow {
 
 This syntax is simpler and easier to use with the {ref}`strict syntax <strict-syntax-page>`. See {ref}`workflow-handlers` for details.
 
-<h3>Improved handling of dynamic directives</h3>
+<h3>Simpler syntax for dynamic directives</h3>
 
 The {ref}`strict syntax <strict-syntax-page>` allows dynamic process directives to be specified without a closure:
 
@@ -131,6 +172,8 @@ process hello {
 }
 ```
 
+Dynamic process settings in configuration files must still be specified with closures.
+
 See {ref}`dynamic-directives` for details.
 
 <h3>Configurable date formatting</h3>