Do not enable experimental by default in nightly and snapshot versions

[nicolasstucki]

THIS PR IS TO EVALUATE THE FEASIBILITY OF THIS CHANGE

This scheme was devised as a simple way to enable experimental on non-stable released. This made it impossible to publish a library containing experimental features for a non-experimental version of the compiler. We had -Yno-experimental to test the expected behavior on stable releases. Later we added -experimental which add @experimental to all top-level classes. On a stable release, this has the same effect as enabling experimental features, but it also allows publishing this library (users will need to also be experimental to use it).

We can use -experimental on nightly and snapshot releases to achieve the same behavior as before. By doing this the -Yno-experimental flag is no longer needed and can be removed.

We will need to use -experimental in all our tests to enable experimental by default. We can add this compiler flag to the default settings. We also need a few tests that do not use -experimental to test the behavior of @experimental. These can be added in tests/*-no-experimental/. Not all tests have -experimental enabled, this will be added on a need basis.

With this we detected one bug, the runtime staging compile crashes if the code uses experimental features. To fix this we enable -experimental by default in this compiler. Note that the experimental-ness checks will have been done by the compiler that compiled the quotes.

[odersky]

I am not against this specific change, but I note that currently experimental is far too restrictive. The philosophy seems to be: if you use experimental you are a bad person, and we grudgingly let you use it sometimes depending on your tool setup. We won't give you a bullet proof way to use this stuff. Before it was "use it with a nightly compiler". How do I do that? Who knows! It depends on what tool you use, every one is different and some might not work at all! Now it is: you need to compile with -experimental. How do I pass such an option in a bullet proof way to the compiler? Again, who knows!

I just tried to use an experimental feature in sbt console. I could figure out no way to achieve this. If I can't do it, how do we expect random devs to do it? Again, this is proof that our focus just lies in _preventing_people from using it, not in enabling them.

We need to go back to square one and decide what we want from experimental and what we can do to make its usage easy and pleasant.

[nicolasstucki]

The current status of this experiment shows that this approach does not scale well due to the need to enable -experimental everywhere we need it.

An insight from this change is that we often want to enable -experimental because we have a language.experimental.xyz import. Maybe there is a way to take advantage of the fact that an experimental feature was imported to activate the -experimental mode in that project/REPL.

[odersky]

Yes, I think now that we have found a robust way to declare that a unit of code is experimental, we don't need to be obtuse when it comes to declaring that something is experimental.

So:

• Every(*) experimental language import makes a unit experimental

• The -experimental flag makes a unit experimental

• We could even define an experimental language import mode that can be imported like this:

    import language.experimental.mode
  

  The idea is that this would turn on experimental where access to the setting is difficult (e.g. repls or worksheets)

(*) Caveat: There is currently one exception: capture checking, and there might be more in the future. See my next comment.

[odersky]

Another question is the virality of experimental. In general experimental is viral, clients need to be experimental themselves. But there could be options (such as capture checking, or initialization checking) where clients that don't opt in to be experimental are not affected. For instance if I have file A with a language.experimental.captureChecking import and for B that uses A, then file B does not need to be experimental. capture checking A has no effect on B.

We currently implement that scheme by making a special exception for capture checking. Maybe we can generalize it. But the question is how do we decide that an experimental feature is not viral?

[nicolasstucki]

Replaced with #19807