Need another escape hatch for experimental
See original GitHub issue@experimental definitions and experimental language imports can currently only be used on code that is itself @experimental or that is compiled with a nightly version of the compiler.
This effectively locks experimental away in the poison cabinet.
For instance, I see no practical scheme to use experimental features in the compiler itself. This is a shame. First, there is no issue in using experimental features in the compiler. If they change, we can change the compiler as well, it’s the same repo. So the stability argument does not apply. Second, we forgo the large benefits of dog-fooding, which means that experimental features are pushed out with much less testing and user experience than would have been the case otherwise.
To change that, I propose we create an setting -Yexperimental
which would make the compiler pretend it is a nightly version. I am not sure what this should mean for the Tasty version, however.
Issue Analytics
- State:
- Created a year ago
- Comments:14 (10 by maintainers)
Top GitHub Comments
How does it work with tasty? Wouldn’t it be a possibility that the tasty changes and breaks all the plugins downstream which compile with stable versions? We would need a tooling community build to test that out or Mima for Tasty?
Including all the tooling authors? This works when we have a proper API to use, otherwise we should be careful about big changes that can impact tooling especially using experimental.
Isn’t it exactly what experimental is supposed to be? We don’t want to use experimental in a real live code since it’s something we are not yet sure about. And people might have less confidence in the compiler if it uses experimental features.
Overall, this change seems a bit hostile for tooling and I would try to keep in my mind that tooling authors can’t be taken for granted. Aside from Metals of course 😅
In any case, I think this should be brought up as a SIP for a committee vote.