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

Deprecate -Xfuture #7328

Merged
merged 2 commits into from Dec 4, 2018
Merged

Deprecate -Xfuture #7328

merged 2 commits into from Dec 4, 2018

Conversation

@adriaanm
Copy link
Member

@adriaanm adriaanm commented Oct 10, 2018

Deprecates but doesn't remove the command-line option.

Close scala/scala-dev#471
Fix scala/bug#8361

@scala-jenkins scala-jenkins added this to the 2.13.0-RC1 milestone Oct 10, 2018
@@ -461,7 +458,7 @@ trait ScalaSettings extends AbsScalaSettings

/** Groups of Settings.
*/
val future = BooleanSetting("-Xfuture", "Turn on future language features.") enablingIfNotSetByUser futureSettings
val future = BooleanSetting("-Xfuture", "Deprecated. Does nothing.").withDeprecationMessage("Use -Xsource instead.")

This comment has been minimized.

@eed3si9n

eed3si9n Oct 10, 2018
Member

There's no future
In England's dreaming

This comment has been minimized.

@som-snytt

som-snytt Oct 11, 2018
Contributor

I came here to say "there is no future", but instead I am grateful for @eed3si9n . Note that maybe it's worse if the future "does nothing".

This comment has been minimized.

@adriaanm

adriaanm Oct 12, 2018
Author Member

Updated message. It needn't be gloomy.

Remove the last reference to `settings.future`
@adriaanm adriaanm force-pushed the adriaanm:drop-Xfuture branch from 9de7b3f to 818abd6 Oct 11, 2018
Leave the now no-op command line option for now.
@adriaanm adriaanm force-pushed the adriaanm:drop-Xfuture branch from 818abd6 to 67195a5 Oct 12, 2018
@som-snytt
Copy link
Contributor

@som-snytt som-snytt commented Oct 12, 2018

compare #6974

@@ -1,4 +1,4 @@
// scalac: -Xfuture
// scalac: -Xsource:3.0

This comment has been minimized.

@smarter

smarter Oct 12, 2018
Contributor

How about 2.14 instead of 3.0 ? We need to spread the pain a bit :).

This comment has been minimized.

@adriaanm

adriaanm Oct 12, 2018
Author Member

This represents a lot of pain, for not much gain (that I can see). Open to discuss, but my initial position is mild skepticism. I'm not yet convinced this should even be in 3.0

This comment has been minimized.

@smarter

smarter Oct 12, 2018
Contributor

But it's already deprecated no ?

This comment has been minimized.

@adriaanm

adriaanm Oct 12, 2018
Author Member

Yes, I'm not sure anymore deprecation is the right thing to do.

This comment has been minimized.

@adriaanm

adriaanm Oct 12, 2018
Author Member

Anyway, I probably hold the minority opinion on this. The remaining discussion is to decide the version. We could do 2.14 if people think that's better.

This comment has been minimized.

@SethTisue

SethTisue Oct 12, 2018
Member

hmm, I'm surprised this is controversial at all, I would like to understand your (Adriaan's) thinking here. maybe we should discuss further in a more visible place? (scala/bug#8035, or Discourse?)

This comment has been minimized.

@xeno-by

xeno-by Oct 12, 2018
Member

If we want to remove this in 2.14, I think we'll need to vote for that at a SIP meeting.

This comment has been minimized.

@adriaanm

adriaanm Oct 15, 2018
Author Member

Since when is the committee concerned with the precise version number a deprecation happens in? It doesn't even get to specify the version in which a new feature will be implemented: https://docs.scala-lang.org/sips/sip-submission.html says

the committee asks the compiler maintainers to indicate the earliest version of Scala that can include the language change.

Note: asks the maintainers, it doesn't tell us. And we're also talking about the earliest version. Since deprecation is kind of the dual, we'd be asked about the latest version something should be deprecated. However, there isn't even a SIP process for deprecation -- that usually happens together with the new feature that replaces it. That particular feature will be discussed as part of the Scala 3 sip.

If you think the SIP committee mandate should be expanded to include require precise versions in which we should implement/remove things, please put that on the agenda for November. I'll say now that I'm not in favor.

@SethTisue SethTisue merged commit 238e5c2 into scala:2.13.x Dec 4, 2018
4 checks passed
4 checks passed
@scala-jenkins
cla @adriaanm signed the Scala CLA. Thanks!
Details
@scala-jenkins
combined All previous commits successful.
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@scala-jenkins
validate-main [5084] SUCCESS. Took 34 min.
Details
@SethTisue
Copy link
Member

@SethTisue SethTisue commented Dec 4, 2018

the 2.14 vs 3.0 question can always be adjusted later

@SethTisue SethTisue changed the title Drop last usage of -Xfuture Deprecate -Xfuture Apr 4, 2019
@shimamoto shimamoto mentioned this pull request Jul 25, 2019
7 tasks done
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment