Cannot use experimental language features in @experimental code

[odersky]

Compiler version

3.1.0

Minimized example

import language.experimental.erasedDefinitions
import annotation.experimental

@experimental
erased class CanThrow[-E <: Exception]

Output

Error:  2 |import language.experimental.erasedDefinitions
Error:    |       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Error:    |Experimental features may only be used with a nightly or snapshot version of the compiler

Expectation

Should compile.

Otherwise, we cannot use experimental language features in @experimental code.

I think what happens is that we check the compiler version when we analyze the import statement. We should wait with it until we need to check whether the language import is enabled. If all these tests are from experimental scopes, this should be permitted.

[nicolasstucki]

It is expected to have a compilation error on import language.experimental.erasedDefinitions if we tell to the compiler to fail on the use of experimental features with -Yno-experimental.

[odersky]

Yes, but I think in terms of language features that's wrong. We should check on use, not import.

[odersky]

Can we wait with enforcing @experimental until 3.2? I don't think it's baked yet. The problem shown by CanThrow is not very special and is in fact quite typical. @experimental has already the reputation of being quixotic. If we cannot make it 100% usable we should not impose it now.

[nicolasstucki]

The current version is conservative, if we relax it we will need to add custom logic for each experimental feature on a case-by-case basis.

• namedTypeArguments should fail on import
• genericNumberLiterals could be checked at use site (not sure how)
• erasedDefinitions could be checked at the definition site. An @experimental erased def ... would be accepted.
• fewerBraces should fail on import

[nicolasstucki]

Can we wait with enforcing @experimental until 3.2?

This is too dangerous in general. For CanThrow we can just not enforce it for the standard library. We would need to be extra careful to not leak experimental features that are not in an @expreimental definition.

[nicolasstucki]

Oh no, but then we would not be able to bootstrap on a stable compiler. The simples change seems to be to special case erasedDefinitions now.

[odersky]

Yes, I think at least so far erasedDefinitions is special since it affects allowed modifiers. For all other features we could have the experimental import inside the @experimental scope.

[odersky]

But in fact that will probably not work either. Since the parser does not know about experimental contexts.

[odersky]

This is too dangerous in general.

Why is it dangerous? That's what I am not getting.

[nicolasstucki]

The idea would be to not fail on the import of erasedDefinitions in any situation. Then, after typing, check that all erased definitions are in an experimental scope.

[odersky]

I just had another idea. We could delay the experimental warning on experimental imports to typer. Then, allow an experimental import if one of the following is true:

• the import is in an experimental scope
• the import is in a scope where all definitions are marked @experimental and there are no expressions

[nicolasstucki]

That might be a bit more complex. My version only requires the delay of the erasedDefinitions import. This might be the first step before moving all the checks after parser.

[odersky]

Let me try it anyway. I prefer not to need special treatments and exceptions. It's very awkward documenting them, to start with.