Skip to content
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

Closed
prolativ opened this issue Jul 16, 2021 · 7 comments · Fixed by #13155
Closed

Experimental trait cannot be instantiated anonymously #13091

prolativ opened this issue Jul 16, 2021 · 7 comments · Fixed by #13155
Assignees
Milestone

Comments

@prolativ
Copy link
Contributor

Compiler version

3.0.3-RC1-bin-20210715-7899462-NIGHTLY

Minimized code

import annotation.experimental
@experimental trait Foo
val foo = new (Foo @experimental) {}

Output

-- Error:
3 |val foo = new (Foo @experimental) {}
  |          ^
  |    extension of experimental trait Foo must have @experimental annotation

Expectation

It should be possible to create an instance of a trait marked as experimental without having to create a helper class like

@experimental class Bar extends Foo
val bar = new Bar

The problem seems to also affect classes with a refinement.

@odersky odersky self-assigned this Jul 16, 2021
@odersky
Copy link
Contributor

odersky commented Jul 16, 2021

I wonder why have that restriction in the first place? cc @nicolasstucki @sjrd

@odersky odersky removed their assignment Jul 16, 2021
@sjrd
Copy link
Member

sjrd commented Jul 16, 2021

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.

@odersky
Copy link
Contributor

odersky commented Jul 16, 2021

But I don't see how extends is different from uses. Classes using an experimental class don't need to be marked as experimental.

@sjrd
Copy link
Member

sjrd commented Jul 16, 2021

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.)

odersky added a commit to dotty-staging/dotty that referenced this issue Jul 16, 2021
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
@odersky
Copy link
Contributor

odersky commented Jul 16, 2021

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?

@odersky
Copy link
Contributor

odersky commented Jul 16, 2021

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.

nicolasstucki added a commit to dotty-staging/dotty that referenced this issue Jul 26, 2021
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
@nicolasstucki
Copy link
Contributor

We do not require the annotation on anonymous classes. This one slipped through the checks.

@Kordyjan Kordyjan added this to the 3.1.0 milestone Aug 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment