✅ Deploy Preview for nextflow-docs-staging canceled.

In my opinion, this behaviour is strange or at least incomplete; a user could do something like this:

record Sample{
	id:String
	num: Integer
}

workflow{
	def a = record(id: "hello", num: 1) as Sample
	if (a instanceof Sample){
		println("It is a sample")
	}else{
		println("not a sample")
	}
}

You create a record, cast it to Sample and then check the type with instanceof and see that it is not really a Sample. Not sure, if it is possible to replace the instanceof by a method that checks the defined fields instead of the class. At least we should add a note describing it in the docs. (I haven't found anything about it)

Good catch. I actually meant to implement a compiler transform for that as well, so that sample instanceof Sample becomes something like _instanceof_record(sample, Sample) which performs a runtime check. I guess that fell through the cracks during development

I will try to implement that in this PR

@jorgee added the runtime check for instanceof, ready for review

The new cast that redirects to asType is breaking a test that is casting a list to a Tuple.

Expected no exception to be thrown, but got 'nextflow.exception.ScriptCompilationException'
Expected no exception to be thrown, but got 'nextflow.exception.ScriptCompilationException'
	at spock.lang.Specification.noExceptionThrown(Specification.java:136)
	at nextflow.script.parser.v2.ScriptLoaderV2Test.should strip unsupported type annotations(ScriptLoaderV2Test.groovy:302)
Caused by: nextflow.exception.ScriptCompilationException: Script compilation failed
	at nextflow.script.parser.v2.ScriptLoaderV2.parse0(ScriptLoaderV2.groovy:129)
	at nextflow.script.parser.v2.ScriptLoaderV2.parse(ScriptLoaderV2.groovy:90)
	at nextflow.script.parser.v2.ScriptLoaderV2Test.should strip unsupported type annotations(ScriptLoaderV2Test.groovy:298)
Caused by: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
Main: 3: The class nextflow.script.types.Tuple<java.lang.String, java.lang.String, java.lang.String> (supplied with 3 type parameters) refers to the class nextflow.script.types.Tuple which takes no parameters
 @ line 3, column 44.
   '1', '1.fastq', '2.fastq'] as Tuple<Stri

                             ^

Good catches. I was wondering about this too, whether to override all cast expressions or not. I updated the cast visitor to preserve the existing behavior and only inject the runtime check for things like as Sample and as List<Sample>

I think the check of the existing Path is still happening in the case of generics. ['no-existing-file.txt'] as List<Path> is throwing the exeception. Maybe is out of the scope of the PR, but I am wondering why the cast of TypeHelper must check the existence of the file.

Some users have asked to make checkIfExists: true the default in the file() function, because this is almost always what you want (i.e. reading a file), whereas you would only want checkIfExists: false when writing a new file. But we can't realistically do that because file() is used everywhere. It would be a big breaking change

Instead, I introduced a new default with the params block, where Path params verify the file existence, and new files must be declared as String. So the purpose of checking file existence is to verify the existence of input files before they are read. An optional file should be null rather than a reference to a missing file.

The as operator should have the same behavior as the params block since it has the same purpose (validating/converting external data to Nextflow types). The only difference being that params can cast command-line params from string to number/boolean/path.

Since this PR is meant to be a bug fix for 26.04, I restricted the changes to only affect new use cases (parameterized types and record types). But we should probably also apply this behavior to as Path in the future. I would consider it an aspect of the strict parser since it is just a stricter validation of what users are already doing.