method override acts as escape hatch for `@experimental`

[bishabosha]

Compiler version

3.3.0-RC3

Minimized code

import annotation.experimental

trait Foo { @experimental def bar = 23 }

object Bar extends Foo { override def bar = 42 }

@main def Test = println(Bar.bar)

Output

42

Expectation

I expected an error at the use site of Bar.bar.

Perhaps also we should error at the definition when overriding experimental definitions to also add experimental.

[bishabosha]

this one is not a bug, due to rules of JVM.

Maybe add regression test still

[SethTisue]

Perhaps also we should error at the definition when overriding experimental definitions to also add experimental

seems like a good idea to me

[dwijnand]

Perhaps also we should error at the definition when overriding experimental definitions to also add experimental

seems like a good idea to me

I disagree. Imagine Bar is scala.tools.dotc.internal.CompilerImpl and Foo is scala.tools.dotc.interface.Compiler and exposes its method as @experimental, then I shouldn't have to pollute CompilerImpl.

[SethTisue]

Hmmm.... well that gives me pause, but doesn't necessarily convince me. Presumably CompilerImpl would be package-private. Perhaps the rule @bishabosha proposes only makes sense for public methods?

I admit to being unfamiliar with how @experimental already interacts with visibility, if it does interact.

[sjrd]

The rules should be the same as @deprecated: when A <: B, you can have B.m deprecated while A.m is not. But you can't have it the other way around. The same should apply to @experimental.

[bishabosha]

So a class that extends a trait (where the trait has an experimental method) should now commit to supporting that new method forever, even if the trait eventually removes the experimental method? (because it replaced by a different design)

I think experimental seems to imply "this doesn't exist unless in experimental mode" (unless another super type has a non-experimental method with the same signature)

[sjrd]

So a class that extends a trait (where the trait has an experimental method) should now commit to supporting that new method forever, even if the trait eventually removes the experimental method? (because it replaced by a different design)

Yes, absolutely. If it does not want to commit to it, the subclass should also mark it @experimental.

[bishabosha]

So a class that extends a trait (where the trait has an experimental method) should now commit to supporting that new method forever, even if the trait eventually removes the experimental method? (because it replaced by a different design)

Yes, absolutely. If it does not want to commit to it, the subclass should also mark it @experimental.

Ok so e.g. if we add @experimental def defaultArgument(index: Int): Any to deriving.Mirror.Product (with a concrete default implementation) then the synthetic override in companion objects should probably declare it experimental also

[SethTisue]

I see y'all's point of view, but it just seems to me like it's expecting a lot of library authors to remember to do this. Sure, if this bites them, then afterwards we could fold our arms and say "we told you! right there in plain sight on issue 17291, behind the sign saying 'beware of the leopard', didn't you read it? everyone knows issue 17291!" I'm having trouble feeling satisfied with this.

What about a warning, that library authors could choose to silence with @nowarn?