Handle experimental features in releases

[nicolasstucki]

To properly handle the usage restrictions on experimental features we need:

• A flag to enable experimental feature imports (-Xenable-experimental). This flag will enable the use of experimental features trough language imports or language flags.
• When publishing we need let the binary know if it is a stable release or not (i.e. nightly).
  • Nightly: allows the use of -Xenable-experimental
  • Stable: disallows the use of -Xenable-experimental

[odersky]

I am strictly against a flag. The whole point of language imports is that you don't need a flag a anymore! Flags are obscure, we never know which ones are set, and we don't know how to set them in many situations. For instance, quickly: how do you set a flag in a worksheet? in a notebook? in sbt? in mill? Language imports much better: Clear, readable, self-documenting, easy to discover.

What we should do is enable the experimental language import only for unstable releases.

[nicolasstucki]

We should at least have a flag to enable or disable non-release/release on a non-release artifact to be able to test it properly. @sjrd proposed to do it this way. I had originally proposed the opposite, a blag that can be used in nightlies to make it run as if it were a release artifact. This is important to test if the experimental features are properly disabled in the release build before getting we release.

[odersky]

I think having a -Yrelease flag for internal testing would work.

[nafg]

Maybe it would be more clear if it's called something more like -Ystable-features-only or -Yno-unstable-features

[liufengyun]

The standard library depends on the experimental feature erased. If we were to compile the standard library, we need to break the rule.