Enable 'some' experimental features by default in devel

[nc-x]

#16878 (comment)

Maybe, for devel we can enable a few experimental features by default
(features that are supposed to be very close to the finish line, but require a bit of usage to find any major issues).
Three examples would be orc, strictFuncs and strictNotNil.
So, in config/nim.cfg we enable these features in devel.
Anybody using devel would be testing these features then.
Before releasing any new stable version of Nim, these experimental features can be disabled again.
If all goes well these features can be promoted to stable.
This is similar to how it works in Rust and has worked well for them.

@Araq's reply -
#16878 (comment)

Three examples would be orc, strictFuncs and strictNotNil. So, in config/nim.cfg we enable these features in devel.

Good idea. We know that --gc:orc doesn't work yet but I know the other options were tested with bootstrapping. And we should ensure it stays this way, yes.

[nc-x]

@Araq
I tried bootstrapping the compiler with strictNotNil, but the number of warnings is too much, and printing all those warnings to the console makes build times very high...
So, before it can be enabled to build the compiler, the compiler/stdlib code will need to be cleaned up.

[timotheecour]

I prefer the following approach:

nim's CI should test important_packages with a matrix of options we specify, eg:

matrix: "--gc:orc; --experimental:dynamicBindSym --experimental:forLoopMacros --experimental:caseStmtMacros; ..."

this can be achieved reliably via nim-lang/RFCs#336 which enables passing NIM_CONF=/pathto/custom_config.nims for each set of flags in the matrix (/pathto/custom_config.nims is generated on the fly for each set of flags).

Because it's an environment variable, it applies to subprocesses so that this would work for most packages, even if, say, nimble test calls exec "nim c -r tests/tbar"; and it doesn't require changing those packages either.

This is a better approach, because:

• we don't break users code in devel until a flag is indeed ready to become the default
• we don't have to wait for a flag to be "almost ready" to start testing it in important_packages, avoiding a chicken and egg problem

[ringabout]

More experimental features are enabled since Nim 2.0