I appreciate it is probably coming from automated lint/format but is the latter here really better for anyone to read? Before:

def extension = args.contains("--output-type b") || args.contains("-Ob") ? "bcf.gz" :
                args.contains("--output-type u") || args.contains("-Ou") ? "bcf" :
                args.contains("--output-type z") || args.contains("-Oz") ? "vcf.gz" :
                args.contains("--output-type v") || args.contains("-Ov") ? "vcf" :
                "vcf"
def stub_index = args.contains("--write-index=tbi") || args.contains("-W=tbi") ? "tbi" :
                 args.contains("--write-index=csi") || args.contains("-W=csi") ? "csi" :
                 args.contains("--write-index")     || args.contains("-W") ? "csi" :
                 ""

After:

def extension = args.contains("--output-type b") || args.contains("-Ob")
    ? "bcf.gz"
    : args.contains("--output-type u") || args.contains("-Ou")
        ? "bcf"
        : args.contains("--output-type z") || args.contains("-Oz")
            ? "vcf.gz"
            : args.contains("--output-type v") || args.contains("-Ov")
                ? "vcf"
                : "vcf"
def stub_index = args.contains("--write-index=tbi") || args.contains("-W=tbi")
    ? "tbi"
    : args.contains("--write-index=csi") || args.contains("-W=csi")
        ? "csi"
        : args.contains("--write-index") || args.contains("-W")
            ? "csi"
            : ""

An alternate way to implement it so the formatter shouldn't mess with it, is

def extension_map = [
    ["--output-type b", "-Ob"]: "bcf.gz",
    ["--output-type u", "-Ou"]: "bcf",
    ["--output-type z", "-Oz"]: "vcf.gz",
    ["--output-type v", "-Ov"]: "vcf"
]

def extension = extension_map.find { flags, ext -> flags.any { args.contains(it) } }?.value ?: "vcf"

def index_map = [
    ["--write-index=tbi", "-W=tbi"]: "tbi",
    ["--write-index=csi", "-W=csi", "--write-index", "-W"]: "csi"
]

def stub_index = index_map.find { flags, idx -> flags.any { args.contains(it) } }?.value ?: ""

but I guess this makes it harder to read.

Yeah I don’t know if there’s a particularly “nice” way, but I am not convinced the auto-formatter isn’t making things actively worse right now.

I this particular case it is, but these nested if's should be dealt with better I think if there's more than 2 options. It would be better to have switch expressions, but we have to deal with it in other ways.

You can always start a petition to bring back

switch

😅 @Ben Sherman and I have discussed it a few times, it's not a technical reason, only a simplicity / lack of particularly good use cases for it.

I thought he said he wanted something similiar to Rust match implementation, but I don't understand the difference

I like @Mahesh Binzer-Panchal’s solution

which? The closure (2nd) or the map (1st)?

You can always start a petition to bring back

switch

😅 @Ben Sherman and I have discussed it a few times, it's not a technical reason, only a simplicity / lack of particularly good use cases for it.

🙏🙏🙏🙏🙏🙏🙏🙏 The only part of the strict syntax changes which truly has never made sense to me... -- Agreed that the config map approach is a nice alternative though - easily extensible and separates the definitions from the selection!

which? The closure (2nd) or the map (1st)?

Both

Bah, of course the linter doesn't like the closure.

I mainly wanted to give us the ability to craft a pattern matching syntax for Nextflow rather than being constrained by existing Java syntax/semantics but yes I would like to develop a

match

expression or just bring back

switch

expressions if it makes sense

-> https://github.com/nextflow-io/nextflow/pull/7027