Allow for future deprecation #30785
Labels
A-lint
Area: Lints (warnings about flaws in source code) such as unused_mut.
C-enhancement
Category: An issue proposing an enhancement or a PR with one.
Comments
aturon
added
the
A-lint
|
cc #30459 |
|
Isn't this more of an RFC issue? |
|
@steveklabnik I don't think so -- we don't need an RFC to do this, we just need to implement it. |
steveklabnik
added
the
C-enhancement
|
RFC #1270 explicitly notes the possibility of future deprecation, but cautions that this implies a semver dependency. OTOH, |
|
Triage: no change. |
3 tasks
kennytm
added a commit
to kennytm/rust
that referenced
this issue
Apr 3, 2018
…isdreavus,GuillaumeGomez Handle future deprecation annotations This adds special handling to the `since` parameter of the `deprecated` attribute: in particular, if the `since` version exceeds the version of the compiler, the deprecation notice will not be printed; but a note is added to the documentation stating that the item will be deprecated in a later version. (I've used `since` for this, rather than adding a new attribute, because it's more seamless and, I feel, intuitive. Plus it involves less code churn.)   This is a prerequisite for doing things renaming methods in the standard library (e.g. rust-lang#30459). Resolves rust-lang#30785.
kennytm
added a commit
to kennytm/rust
that referenced
this issue
Apr 4, 2018
…isdreavus,GuillaumeGomez Handle future deprecation annotations This adds special handling to the `since` parameter of the `deprecated` attribute: in particular, if the `since` version exceeds the version of the compiler, the deprecation notice will not be printed; but a note is added to the documentation stating that the item will be deprecated in a later version. (I've used `since` for this, rather than adding a new attribute, because it's more seamless and, I feel, intuitive. Plus it involves less code churn.)   This is a prerequisite for doing things renaming methods in the standard library (e.g. rust-lang#30459). Resolves rust-lang#30785.
bors
added a commit
that referenced
this issue
Sep 5, 2018
Add trim_start, trim_end etc.; deprecate trim_left, trim_right, etc. in future Adds the methods: `trim_start`, `trim_end`, `trim_start_matches` and `trim_end_matches`. Deprecates `trim_left`, `trim_right`, `trim_left_matches` and `trim_right_matches` starting from Rust 1.33.0, three versions from when they'll initially be marked as being deprecated, using the future deprecation from #30785 and #51681. Fixes #30459.
|
I think it wold sometimes be useful to get warnings for using items deprecated in the future, see #55892. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We've long wanted the ability to say "deprecated since" for a future version of Rust. The motivation is that, currently, deprecation goes into effect immediately, even though in some cases the replacement for the deprecated item hasn't hit the stable channel yet. By "timing" the deprecation to a given release, we can make the decision and land the replacement, and have it automatically go into effect at the right time.
The idea would be that the deprecation does not warn until the compiler version is at least the version labeling the deprecation.
We could also pipe this information into rustdoc, to give a heads up on the forthcoming deprecation.
The text was updated successfully, but these errors were encountered: