With the ability to import macros using use statements, I was thinking it would be nice to be able to import macros (or anything, really) into a crate's global namespace with use, for example use (crate) log::prelude::*, similar to how #[macro_use] currently does with macros.
This would also be useful for importing custom derive macros that depend on certain types being available in the current namespace, which is something I've run into with amethyst: The derive implementation is available, but will fail to compile if you don't import all the types the derive implementation references.
As it relates to module organization, I tend to take a more java-like approach (I know... boooo) in that I like to break up my code into smaller files, but then find having to manage imports a bit of a pain. It would be nice if I could import types once (use (mod) foo::*) which would import all of foo's types into the current module and all submodules' namespaces.
When thinking about features like this, it's easy to gloss over details that would either make it not viable from an implementation standpoint, or perhaps confusing or provide footguns. So my question is: Why would this be a bad idea?
This should be considered a bug in the derive. It shouldn't be able to break no matter the environment it's used in.
(This requires assuming that the crate you care about implementing for is available at ::crate_name (at least for now (def-site hygeine when)), but that at least isn't too much to ask.)
I think with the "retiring" of #[macro_use], it'd be worth to reevaluate "custom preludes" as a way of solving this problem of names you want to be globally available to the crate.
(Having custom "prelude" members for merely a subtree seems a bit much; custom preludes are already a hard sell as you introduce unannounced names to a scope, but you only have to check for one declaration to check the custom prelude, whereas it could be anywhere with "prelude-capable use".)
As it relates to Amethyst, there are multiple inter-dependent crates that make up the main amethyst crate, which re-exports each underlying crate under the amethyst namespace. For example, the amethyst_animation crate is re-exported as amethyst::animation.
The crux or the issue is that when this particular derive macro is used internally, the types are imported via the dependent crate (eg use amethyst_core::SomeDeriveDependency) but in user code that same type would be referenced using the re-exported namespace amethyst::core::SomeDeriveDependency.
With that being the case, the derive macro cannot make assumptions with regards to the fully qualified namespace of the types it references, so it expects them to be present in the current namespace unqualified.
IMO, amethyst is organized in a perfectly reasonable fashion, and there doesn't seem to be a nice workaround for this particular issue.