If I use a deprecated function inside a deprecated function I get a warning.
It seems to me that this is not the appropriate behavior as deprecating a group of related functions is common, and having those warning will be quite annoying.
On a similar note,
The warnings for unused functions. If a function is used by an unused function this should the warning should only show on the top level genuinely unused function. Then I can use the unused warning to find exactly what I'm forgetting to call.
Does anyone else agree with this , or is this just me?
I also ran into something like this and ended up sprinkling allow(deprecated) everywhere, surprisingly even on the deprecated trait itself. I almost wonder if it should be possible to say something like deprecated(pub = true) to only externally deprecate the item, and leave it undeprecated internally.
Rust generally follows the strategy of providing all the errors and warnings it can, so that you can fix all of them in one pass without having to re-run the compiler to see more errors. I personally love the way Rust warns about everything unused, including things used by code that is itself unused. A complete list of what isn't used helps if you're going to delete them (you know everything to delete), and it gives you a menu of things to start using if you're adding code. Rust can't assume that there's a "top-level function" you want to call; perhaps you need to add calls to several things and delete others as unused.
Regarding deprecated things, however, that does seem a little different. Sometimes you would want to migrate the internals of deprecated functions to use a different non-deprecated implementation, but other times it could indeed make sense to say "deprecated except for use by other deprecated things". I don't know that that's a choice you'd want to make at a crate level; rather, I like the idea of having a "deprecated outside this crate" concept:
This seems reasonable to me: deprecated(pub) could deprecate uses from outside the crate, and perhaps deprecated(pub(crate)) could deprecate uses outside the module.
For deprecated though, it's only for items you are also deprecating that it's basically irrelevant. You aren't planning on maintaining either of them.
Highlighting deprecations within crate was handy and helped me to go through and fix the whole still live area.
It might be useful to have a way to allow deprecated items from a particular path. For example #[allow(deprecated(ndarray::parallel))] would allow deprecated items from below that path. This would be useful inside the crate itself and with external crates.
I know paths aren't always canonical, so it might be simpler to implement in a stable and predictable way with just a crate specifier, but that's still more flexible than just "allow(deprecated)"