std predule macros should be available in std::prelude

[CAD97]

Proposal

Problem statement

The core prelude contains use reexports for most core #[macro_use]d macros (e.g. include!, env!, file!, line!). The std prelude reexports the core prelude macros but does not provide use reexports for the std prelude macros (e.g. prinln!, vec!).

Motivation, use-cases

The primary motivation is consistency. #[macro_use] extern crate is discouraged in favor of using named imports for macros; std should name all of the prelude names in the prelude import, rather than relying on #[macro_use].

A primary use-case is conditionally-std crates. There's currently two main ways to spell conditional-std-ness:

// case 1: cfg the no_std
// this always gets you the applicable prelude with #[macro_use]
// but makes avoiding the use of std:: in no_std-compatible code harder
// it is also nonuniform with an alloc feature
#![cfg_attr(not(feature = "std"), no_std)]
extern crate core;
#[cfg(feature = "alloc")]
extern crate alloc;

// case 2a: cfg extern std
// this restricts you to the core prelude even with --all-features development
// but `use std::prelude::edition::*;` isn't enough to get back
#![no_std]
#[cfg(feature = "alloc")]
extern crate alloc;
#[cfg(feature = "std")]
extern crate std;

// case 2b: also use #[macro_use]
// gets the decl consistency of 2a but with the no_std enforcement issues of 1
// not to mention using #[macro_use] which is all but deprecated
#![no_std]
#[cfg(feature = "alloc")]
#[macro_use]
extern crate alloc;
#[cfg(feature = "std")]
#[macro_use]
extern crate std;

It would be ideal if case 2b can be folded into 2a, where an explicit use std::prelude::edition::* can be added to #[cfg(feature = "std")] modules to get access to the full std prelude.

Solution sketches

Add reexports for the macros not currently available through the prelude into the prelude. This includes macros in core, alloc, and std that are imported by #[macro_use] but not yet available in the respective preludes.

In the future (a lang change, not a libs change), consider removing the use of #[macro_use] for the injected extern crate std; and rely on the prelude import instead. This should not change any observable behavior, as the prelude import is injected into every module already. However, this is NOT part of this ACP.

Links and related work

(none)

What happens now?

This issue is part of the libs-api team API change proposal process. Once this issue is filed the libs-api team will review open proposals in its weekly meeting. You should receive feedback within a week or two.

[CAD97]

Obviously, the end goal is the portability lint and reunification of the core/alloc/std facade into one namespace. Even when that eventual perfect future comes, though, having the prelude macros in the prelude module is still better, as it allows #[macro_use] to be a relic of the past rather than something still relevant to what std items are available without being imported.

[m-ou-se]

This seems fine. Feel free to open a PR on rust-lang/rust to make the prelude more consistent by including all macros from the crate root in it.