-
Notifications
You must be signed in to change notification settings - Fork 14
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
Remove language fragmentation -Y
flags. Only -Xsource
allowed henceforth.
#430
Comments
Does that mean popular features like |
What about |
Partial unification, assuming it has proven itself (I’d say it has), will be on by default. Ditto for rangepos. |
I really like this.
I guess those -Y flags related to debugging will stay or renamed? And perhaps things like |
I only intend to change/remove |
These affect language semantics, though I guess they will stay too. |
Yes, exceptions will be needed, just not 19 ;-) I hope the predef/imports options will be consolidated -- there's a PR for that. |
|
I guess no more |
Sounds good to me, you may want to figure out what should happen to the billion flags recommended in https://tpolecat.github.io/2017/04/25/scalac-flags.html |
I suggest replacing |
Flags to increase verbose output like |
I'm very sympathetic to your desire to minimize unnecessary language fragmentation. Nevertheless, there is a need to ship compilers with more fine-grained control over new or experimental features so that people can get experience with them which can in turn influence the design, or indeed acceptance of the feature. Concretely, Typelevel Scala needs a mechanism of this sort. We could continue to use We also need to think about Dotty. It's making language changes which it would be beneficial to backport to Scala (eg. scala/scala#6037) but which would break existing reasonable code if unconditionally enabled. Should there be an I would also be fairly strongly in favour of deprecating |
I think Typelevel Scala users might actually like and prefer a |
I think warnings like that should be moved out of the compiler to Scalafix linters (or even better rewrites), where (a) there are already many more possible warnings, opt-in/opt-out, and (b) they can become rewrites. The one I'm concerned about is |
For If plugins could contribute prefixed options, avoiding ugly |
I'm not sure if I like that. Additional tooling always comes with a cost. |
heads up, |
I split the |
scala/scala#6505 is merged for 2.13.0-M4 |
I'm confused why |
I must say I strongly disagree with removal of linter-like flags. user shouldn't need to know ecosystem to write safe code. Linting has to be done by the compiler or in some other way that doesn't require knowing about Scalafix (e.g. by integrating it with sbt by default or something like that). When I start learning new language it's a matter of months before I get familiar with the ecosystem and I want get as much help from tooling as possible in this rough period. It would be nice to have tpolecat's flags enabled by default btw. |
Linting doesn't change the language. I'm fine with linter flags staying, and I'd like them unified under the -Xlint flag. |
The linked PR proposes moving warnings to I need as much help as possible from tooling in the rough period when I'm doing any coding at all. |
Here's another candidate for removal as pointed out by @SethTisue in scala/bug#1472: |
retargeted for 2.13.1 since as far as I know, there is nothing remaining here that is essential for 2.13.0 |
@Krever this could be considered on a case-by-case basis; PRs welcome. (probably better as separate PRs unless there are no-brainers that can be batched.) note that "enabled by default" is one thing and "enabled by default as part of if you want to discuss linter flags further, let's do it on a new ticket, and keep this ticket restricted to language fragmentation flags |
closing since the major work already happened. if there are remaining pieces we can have individual tickets for them. |
note that the reduced set of available options got cleaned up and reorganized in scala/scala#7908 |
I've counted close to 20 flags that change language semantics in various ways. 2^20 variants of the language is unacceptable complexity both for users and maintainers. As of 2.13, -Y flags will no longer be allowed to change language semantics. We will retain
-Xsource
as a migration/preview mechanism. We will clearly list which features can be turned on by specifying a future source version, and as soon as the first milestone of that version is released, the feature will be turned on by default.A feature submitted to our codebase is only accepted if we expect it to become officially supported.
-Xsource
is meant to allow previewing and migrating to the new version that offers this feature by default. If the feature is not of high enough quality to be turned on along with the other-Xsource:N
features, it is not ready for submission to scala/scala.The official Scala compiler is not a vehicle for research/experimentation. There are plenty of alternatives for that. Having many rarely exercised code paths lead to bitrot and undertested code. They also set the wrong expectations for users.
The mechanism is also used by the presentation compiler to simulate older versions of the compiler while running the latest version to provide the IDE experience. We will retain this functionality where appropriate.
The text was updated successfully, but these errors were encountered: