Use destructuring syntax for process record/tuple inputs

[pditommaso]

Summary

• Proposes using the record() function-call notation uniformly for both process inputs and outputs
• Replaces the asymmetric Record { ... } block syntax currently used only in input declarations
• Aligns with existing assignment (=) and type annotation (: Type) patterns already present in process I/O

Current (asymmetric):

input:
sample: Record {         // block syntax, unique to inputs
    id: String
    fastq_1: Path
}

output:
record(id: sample.id, html: file('*.html'))   // function call

Proposed (uniform):

input:
sample: Sample = record(id: String, fastq_1: Path)

output:
result: OtherType = record(id: sample.id, html: file('*.html'))

Test plan

• Review ADR content for accuracy and completeness
• Discuss with team whether this direction aligns with typed syntax roadmap

🤖 Generated with Claude Code

[netlify]

✅ Deploy Preview for nextflow-docs-staging canceled.

Name	Link
🔨 Latest commit	1e47466
🔍 Latest deploy log	https://app.netlify.com/projects/nextflow-docs-staging/deploys/69c5535ae6b7a80008d97858

[bentsherman]

Great discussion overall. I would be keen to incorporate this somehow into the record type ADR, since we did discuss some of these options throughout the process but I didn't include them as alternatives in the original ADR

Would be good to document these alternatives so that we have the clear rationale for the final syntax

[pditommaso]

Updated ADR: Unified constructor notation for record() and tuple()

Key changes in this update:

1. Broadened scope from record-only to all structured types. The proposal now establishes name = constructor(...) as a uniform notation that applies to both record() and tuple(), not just records.

2. Three-tier notation for both constructors:

   tuple(id, file('*.bam'))                          // bare
   out = tuple(id, file('*.bam'))                    // assignment
   out: Tuple<String,Path> = tuple(id, file('*.bam'))  // typed assignment

   Same pattern for record() — bare, assignment, typed assignment.

3. Migration path from classic DSL2 through tuples to records:

   tuple val(id), path(fastq)             // classic DSL2
   in = tuple(id: String, fastq: Path)    // typed — uniform notation
   in = record(id: String, fastq: Path)   // record — just change the keyword

4. Tuple input with inline named types — in = tuple(id: String, fastq: Path) — gives tuples named components while preserving positional semantics, mirroring record input notation exactly.

5. Coexistence example showing both tuple() and record() in the same pipeline with identical notation shape.

The core value: users learn one pattern and apply it everywhere. The only choice is positional (tuple) vs named (record).

[christopher-hakkaart]

I've made two comments: one typo and one language suggestion. Otherwise the docs look good.