Export the `derive` macro at `core::derive` and `std::derive`.

[nik-rev]

Proposal

Export the derive macro at core::derive and std::derive.

Problem statement

The derive macro can only be accessed as core::prelude::v1::derive.

Motivating examples or use cases

I have a custom derive_aliases::derive macro in the derive-aliases crate, which expands to the standard library's derive macro

i.e. this:

#[derive_aliases::derive(..Copy)]

expands into this, if there is a derive alias Copy that expands into Copy and Clone:

#[::core::prelude::v1::derive(Copy, Clone)]

But this is quite an unintuitive path, and it makes it harder for me to describe to the users how the derive_aliases::derive macro expands.

I currently just say it expands to calls at std::derive because most users would assume that's where the absolute path to the derive macro is. But that's misleading because the absolute path is at ::core::prelude::v1::derive

The biggest benefit of this change is that macro authors will be more likely to generate code that uses #[core::derive] instead of #[derive]. The derive_aliases::derive macro can be imported to shadow the built-in derive, meaning most existing macros will have the generated code use derive_aliases::derive instead of derive, which is not the intent, and could lead to problems.

Other benefits include:

• Makes it easier to explain the expansion of my macro to users. Users will naturally assume that the derive macro's full path is at core::derive, but it is not, which I need to explain.
• Consistency. Other macros like assert, matches, panic are available at the crate root
• Makes the test suite of derive_aliases less verbose. Example.
• I can change the derive_aliases::derive macro to expand to core::derive which makes the output of cargo expand, and other macro-expanding tools easier to understand, and less verbose
• Compile times will theoretically be improved because ::core::derive is 6 less tokens than ::core::prelude::v1::derive, although It's likely that there will not be any perceivable different

Solution sketch

I've made a PR: rust-lang/rust#154442

I added a feature gate, but maybe this doesn't need one and it could just instantly become stable (considering how small of a change this is).

Alternatives

Macro authors will try to use an absolute path to the derive macro in generated code. They will try core::derive but it doesn't work, and most likely stop there. That means there will be potential problems if someone has derive_aliases::derive in scope.

Links and related work

What happens now?

This issue contains an API change proposal (or ACP) and is part of the libs-api team feature lifecycle. Once this issue is filed, the libs-api team will review open proposals as capability becomes available. Current response times do not have a clear estimate, but may be up to several months.

Possible responses

The libs team may respond in various different ways. First, the team will consider the problem (this doesn't require any concrete solution or alternatives to have been proposed):

• We think this problem seems worth solving, and the standard library might be the right place to solve it.
• We think that this probably doesn't belong in the standard library.

Second, if there's a concrete solution:

• We think this specific solution looks roughly right, approved, you or someone else should implement this. (Further review will still happen on the subsequent implementation PR.)
• We're not sure this is the right solution, and the alternatives or other materials don't give us enough information to be sure about that. Here are some questions we have that aren't answered, or rough ideas about alternatives we'd want to see discussed.

[kennytm]

Consistency. Other macros like assert, matches, panic are available at the crate root

In terms of consistency, the other attribute macros (at least the stable ones) should be moved to the root too?

• #[global_allocator]
• #[test]

[joshtriplett]

We discussed this in today's @rust-lang/libs-api meeting, and approved this ACP for derive.

We considered whether to put it at top-level or inside a module, but ultimately decided that derive was common enough to be at top-level. That would not block us from also having things like std::derive::foo in the future if we want it as a module name.

If folks want global_allocator and test, those should be a separate ACP. We may or may not want those at top-level; we considered putting global_allocator in the alloc module, for instance.

[nia-e]

We discussed this in today's @rust-lang/libs-api meeting; we agreed to add {core, std}::derive, and for global_allocator/test further ACPs are welcome but we may not necessarily want them directly at the top level in std/alloc/core. Thanks ^^