3 ms·
You could add an edition sensitive non-overridable error to the language, as in, if you use it on edition 2015 or 2018, there is no problem, but on edition 2021
by est31 7y ago
You could add an edition sensitive non-overridable error to the language, as in, if you use it on edition 2015 or 2018, there is no problem, but on edition 2021 and beyond there will be an error in your code that you can't allow away. Then you could have edition specific rustdocs for std where items that are deprecated this way are hidden per default.
However, at least the 2018 edition had the requirement that updating can be done automatically. Ensuring that is hard for library functions.
- irishsultan 7y agoThe problem is that it would be possible for a Rust 2015 module to encounter an Error defined in Rust 202X, so what would happen if that Rust 2015 called `description` on that error if Rust 202X didn't require/allow defining the method `description`?
- est31 7y ago> what would happen if that Rust 2015 called `description` on that error if Rust 202X didn't require/allow defining the method `description`? It's already not required to be defined. Since 1.27.0 there is a default implementation that contains a "description is deprecated" msg. https://doc.rust-lang.org/1.42.0/src/std/error.rs.html#139 https://doc.rust-lang.org/1.42.0/src/std/error.rs.html#139
- GolDDranks 7y ago`description` is still a default method, so the default implementation provided by the Error trait would be called.
- pas 7y agoIf your main crate is edition 202X, then it could warn if you link it with anything that depends on Error.description. Too drastic (and would be dog slow)? Yes, but it's easily possible.