Deprecate -Xfuture #7328
Deprecate -Xfuture #7328
Conversation
| @@ -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.") | |||
There was a problem hiding this comment.
There's no future
In England's dreaming
There was a problem hiding this comment.
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".
There was a problem hiding this comment.
Updated message. It needn't be gloomy.
Remove the last reference to `settings.future`
adriaanm
force-pushed
the
drop-Xfuture
branch
from
9de7b3f
to
818abd6
Compare
Leave the now no-op command line option for now.
adriaanm
force-pushed
the
drop-Xfuture
branch
from
818abd6
to
67195a5
Compare
|
compare #6974 |
| @@ -1,4 +1,4 @@ | |||
| // scalac: -Xfuture | |||
| // scalac: -Xsource:3.0 | |||
There was a problem hiding this comment.
How about 2.14 instead of 3.0 ? We need to spread the pain a bit :).
There was a problem hiding this comment.
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
There was a problem hiding this comment.
But it's already deprecated no ?
There was a problem hiding this comment.
Yes, I'm not sure anymore deprecation is the right thing to do.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?)
There was a problem hiding this comment.
If we want to remove this in 2.14, I think we'll need to vote for that at a SIP meeting.
There was a problem hiding this comment.
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.
|
the 2.14 vs 3.0 question can always be adjusted later |
Deprecates but doesn't remove the command-line option.
Close scala/scala-dev#471
Fix scala/bug#8361