-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Experimental trait cannot be instantiated anonymously #13091
Comments
I wonder why have that restriction in the first place? cc @nicolasstucki @sjrd |
Doing anything with something experimental is experimental. But since there is already an import annotation.experimental it seems that it should be allowed. Then again, it could also be because of the transitivity argument: if you expose a class that extends something experimental, you are in fact exposing that experimental thing as part of your hierarchy, even though you're not experimental. But I don't think we've had this discussion before, so the current restriction is probably not intentional, at least. |
But I don't see how extends is different from uses. Classes using an experimental class don't need to be marked as experimental. |
When you use something, it stays private to your implementation, usually it's fine. If you inherit from something, it always leaks. (It's already a problem with the fact that Scala lets you extend a class or trait with a lesser visibility than yours, which causes actual problems by leaking package-private stuff.) But like I said, we can argue that, but it wasn't part of the discussions/designs, so the restriction should probably be lifted. (Or, if we decide so, consistently applied to every use that leaks in the public API.) |
This PR makes @experimental behave analogously to @deprecated: if you refer to something that's experimental then the compiler version must be a snapshot release. I don't see a reason for more extensive rules. They are likely more damaging than helpful, as i13091 shows. Fixes scala#13091
We have to go over the books here. I almost fell from my chair when I looked at all the anti-experimental checks RefChecks. What are we trying to achieve here anyway? |
I wanted to do a quick fix in #13093 but now realize it will be a huge mess to even update all the tests. So I'll refrain from that. But it should still be done and cut down to the bare minimum. And be done quickly. Experimental is just out, and will be a major hassle for many people. We should err on the side of caution. It seems what we did instead is go completely over the top. |
These calsses will not define new methods in the API for which we would need to check the presence of the annotation. Fixes scala#13091
We do not require the annotation on anonymous classes. This one slipped through the checks. |
Compiler version
3.0.3-RC1-bin-20210715-7899462-NIGHTLY
Minimized code
Output
Expectation
It should be possible to create an instance of a trait marked as experimental without having to create a helper class like
The problem seems to also affect classes with a refinement.
The text was updated successfully, but these errors were encountered: