Drop experimental inheritance checking

[odersky]

IMO it's a foot gun that prevents useful idioms. Concretely I have an @experimental marker trait @caps.Pure that classes can inherit. So far, there was no way to do that except if the inheriting class is also @experimental. This requirement was unconditional. It did not help to be in an experimental scope or to use a snapshot compiler version.

This basically means that @experimental base traits are useless, unless one is prepared to pollute the codebase with sprinkling experimental over all inheriting classes.

On the other hand, I see no useful property that is established by this restriction. The (now deleted) documentation is also silent about the motivation of all this.

[dwijnand]

Perhaps dropping it makes sense. But to be devil's advocate, perhaps the useful property is that it makes it blatantly obvious that a class is experimental, without having to get the compiler or the scaladoc tool to look through the inheritance chain, you can just see it plainly in the source?

I can see how retroactively applying it to an establish codebase may look ridiculous, but perhaps it's a good thing? Might make you stop and think if you really want to make all those classes experimental? And I agree being in an experimental scope or using a snapshot compiler should be exemptions. And to that note, perhaps we should figure out how to annotate a package as experimental?

I don't hold a strong opinion on this.

[odersky]

@dwijnand How do you propose to handle caps.Pure then? I see no way to do it without making capture checking ridiculously cumbersome. And that's not specific to capture checking. It's just that this is the first time anyone has used an @experimental marker trait.

I wish we would spend at least equal measure of thought on how to make things practical than how to prevent things. Right now, my tendency is again to just get rid of the whole experimental thing. It's been so painful to get over all its inadequacies and I have lost an inordinate amount of time on it that would have been better spent elsewhere.

[dwijnand]

I don't know the specifics of the caps.Pure use case to answer that directly. But I think there should be a way to indicate that, for instance, the whole project is experimental.

[odersky]

I don't know the specifics of the caps.Pure use case to answer that directly. But I think there should be a way to indicate that, for instance, the whole project is experimental.

[EDITED example, it made no sense before]

Right now there isn't. Here is a scenario: In one file:

@experimental class A

In the other:

object project:
  class B extends A

This fails in any case because it refers to A, which is experimental. No separate experimental inheritance check is needed.

We should be able to fix it like this:

@experimental object project:
  class B extends A

(or compile with a snapshot version). With the changes in this PR this works. Before, it failed because of the experimental inheritance check.

So the experimental inheritance check achieves nothing useful that is not already covered by the external reference check.

[dwijnand]

Oh, so this is just a cleanup PR removing a redundant check, not actually changing any behaviour? If so, should we look to keeping the various different examples in the test cases? Maybe there's an external reference check test where they can be folded into.

[odersky]

No, it does change behavior. Previously a class A could not inherit from an experimental class without having an @experimental annotation itself. We both agree this is unreasonable. So that behavior was removed.

[dwijnand]

Ah, right. That example makes sense now. Yes, indeed, I agree to the change.