-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
RFC: #[deprecated] for Everyone #1270
Merged
Merged
Changes from all commits
Commits
Show all changes
27 commits
Select commit
Hold shift + click to select a range
edcb3f0
new RFC: deprecation
llogiq 282ed61
word wrapped, thanks to steveklabnik
llogiq 94acabc
clarified how cargo gets rust version
llogiq 043d6a6
Added paragraph on how rustc should handle future target versions
llogiq 2f3acfb
Fleshed out the Motivation section a bit
llogiq d95558d
added future/legacy flags to alternatives
llogiq 06b4163
More explanation about security issues
llogiq 1764038
Clarified the paragraph about cargo/crates.io, also added Policy section
llogiq ef9c632
clarification on insecurity and future-proofing
llogiq 9d18ae4
added Cargo.toml-based target to Alternatives section
llogiq e59e20c
Almost complete rewrite.
llogiq 42af880
Renamed --target to --target-version, reworded Cargo entry default
llogiq c4cf325
added open question about cargo and detailed design about feature fla…
llogiq 151d523
made 'rust' a package attribute instead of a pseudo-dependency
llogiq 186fd91
formatting improvements
llogiq ce6d4e7
Added previous proposal to alternatives, added bikeshedding to unreso…
llogiq 3b9ca85
#[insecure]-flagging removed from RFC, added some open questions (as …
llogiq f0021d0
RFC to make stability attributes public
llogiq a4b0b93
rewrote to start from clean slate, reduce surface area
llogiq e487613
Clarified API items+versioning, more alternatives
llogiq 0aaf9d4
Require since to be exact version, add `d`
llogiq 449ec53
Incorporated chris-morgan's suggestion
llogiq 0c82b6b
More alternatives, relation to internal feature
llogiq feec817
Rename "surrogate" to "use", "since" now optional
llogiq b7597d1
improvements thanks to brson's comments
llogiq c8a726c
Change `use` to semicolon-delimited, expand example
llogiq 8ec2ccd
relegated use to alternatives, user story, clippy
llogiq File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,128 @@ | ||
- Feature Name: Public Stability | ||
- Start Date: 2015-09-03 | ||
- RFC PR: | ||
- Rust Issue: | ||
|
||
# Summary | ||
|
||
This RFC proposes to allow library authors to use a `#[deprecated]` attribute, | ||
with optional `since = "`*version*`"` and `reason = "`*free text*`"`fields. The | ||
compiler can then warn on deprecated items, while `rustdoc` can document their | ||
deprecation accordingly. | ||
|
||
# Motivation | ||
|
||
Library authors want a way to evolve their APIs; which also involves | ||
deprecating items. To do this cleanly, they need to document their intentions | ||
and give their users enough time to react. | ||
|
||
Currently there is no support from the language for this oft-wanted feature | ||
(despite a similar feature existing for the sole purpose of evolving the Rust | ||
standard library). This RFC aims to rectify that, while giving a pleasant | ||
interface to use while maximizing usefulness of the metadata introduced. | ||
|
||
# Detailed design | ||
|
||
Public API items (both plain `fn`s, methods, trait- and inherent | ||
`impl`ementations as well as `const` definitions, type definitions, struct | ||
fields and enum variants) can be given a `#[deprecated]` attribute. All | ||
possible fields are optional: | ||
|
||
* `since` is defined to contain the version of the crate at the time of | ||
deprecating the item, following the semver scheme. Rustc does not know about | ||
versions, thus the content of this field is not checked (but will be by external | ||
lints, e.g. [rust-clippy](https://github.com/Manishearth/rust-clippy). | ||
* `reason` should contain a human-readable string outlining the reason for | ||
deprecating the item. While this field is not required, library authors are | ||
strongly advised to make use of it to convey the reason for the deprecation to | ||
users of their library. The string is interpreted as plain unformatted text | ||
(for now) so that rustdoc can include it in the item's documentation without | ||
messing up the formatting. | ||
|
||
On use of a *deprecated* item, `rustc` will `warn` of the deprecation. Note | ||
that during Cargo builds, warnings on dependencies get silenced. While this has | ||
the upside of keeping things tidy, it has a downside when it comes to | ||
deprecation: | ||
|
||
Let's say I have my `llogiq` crate that depends on `foobar` which uses a | ||
deprecated item of `serde`. I will never get the warning about this unless I | ||
try to build `foobar` directly. We may want to create a service like `crater` | ||
to warn on use of deprecated items in library crates, however this is outside | ||
the scope of this RFC. | ||
|
||
`rustdoc` will show deprecation on items, with a `[deprecated]` box that may | ||
optionally show the version and reason where available. | ||
|
||
The language reference will be extended to describe this feature as outlined | ||
in this RFC. Authors shall be advised to leave their users enough time to react | ||
before *removing* a deprecated item. | ||
|
||
The internally used feature can either be subsumed by this or possibly renamed | ||
to avoid a name clash. | ||
|
||
# Intended Use | ||
|
||
Crate author Anna wants to evolve her crate's API. She has found that one | ||
type, `Foo`, has a better implementation in the `rust-foo` crate. Also she has | ||
written a `frob(Foo)` function to replace the earlier `Foo::frobnicate(self)` | ||
method. | ||
|
||
So Anna first bumps the version of her crate (because deprecation is always | ||
done on a version change) from `0.1.1` to `0.2.1`. She also adds the following | ||
prefix to the `Foo` type: | ||
|
||
``` | ||
extern crate rust_foo; | ||
|
||
#[deprecated(since = "0.2.1", use="rust_foo::Foo", | ||
reason="The rust_foo version is more advanced, and this crates' will likely be discontinued")] | ||
struct Foo { .. } | ||
``` | ||
|
||
Users of her crate will see the following once they `cargo update` and `build`: | ||
|
||
``` | ||
src/foo_use.rs:27:5: 27:8 warning: Foo is marked deprecated as of version 0.2.1 | ||
src/foo_use.rs:27:5: 27:8 note: The rust_foo version is more advanced, and this crates' will likely be discontinued | ||
``` | ||
|
||
Rust-clippy will likely gain more sophisticated checks for deprecation: | ||
|
||
* `future_deprecation` will warn on items marked as deprecated, but with a | ||
version lower than their crates', while `current_deprecation` will warn only on | ||
those items marked as deprecated where the version is equal or lower to the | ||
crates' one. | ||
* `deprecation_syntax` will check that the `since` field really contains a | ||
semver number and not some random string. | ||
|
||
Clippy users can then activate the clippy checks and deactivate the standard | ||
deprecation checks. | ||
|
||
# Drawbacks | ||
|
||
* Once the feature is public, we can no longer change its design | ||
|
||
# Alternatives | ||
|
||
* Do nothing | ||
* make the `since` field required and check that it's a single version | ||
* require either `reason` or `use` be present | ||
* `reason` could include markdown formatting | ||
* rename the `reason` field to `note` to clarify it's broader usage. | ||
* add a `note` field and make `reason` a field with specific meaning, perhaps | ||
even predefine a number of valid reason strings, as JEP277 currently does | ||
* Add a `use` field containing a plain text of what to use instead | ||
* Add a `use` field containing a path to some function, type, etc. to replace | ||
the current feature. Currently with the rustc-private feature, people are | ||
describing a replacement in the `reason` field, which is clearly not the | ||
original intention of the field | ||
* Optionally, `cargo` could offer a new dependency category: "doc-dependencies" | ||
which are used to pull in other crates' documentations to link them (this is | ||
obviously not only relevant to deprecation) | ||
|
||
# Unresolved questions | ||
|
||
* What other restrictions should we introduce now to avoid being bound to a | ||
possibly flawed design? | ||
* Can / Should the `std` library make use of the `#[deprecated]` extensions? | ||
* Bikeshedding: Are the names good enough? |
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
'should' again. This is not optional.