Idea: add std macros to the 2024 prelude module, for regularity

libs
1

Currently, standard macros are not in the std::prelude modules. This means that a use cannot effectively re-introduce a prelude that was disabled with no_std:

#![no_std]

#[cfg(test)]
extern crate std;

#[cfg(test)]
mod tests {
    use std::prelude::rust_2021::*;
    
    extern crate std;

    #[test]
    fn foo() {
        assert_eq!(vec![0, 1, 2].len(), 3);
    }
}

error: cannot find macro `vec` in this scope
  --> src/lib.rs:14:20
   |
14 |         assert_eq!(vec![0, 1, 2].len(), 3);
   |                    ^^^

Is there any reason not to add these macros to the std::prelude::rust_2024 module, so that code can follow the above pattern without a actual crate-wide prelude-affecting #[macro_use]?

I can think of only one complication; it would need care to avoid importing the vec module along with the vec macro.

5 Likes
2

I like it. Is there any way to achieve "import vec! (macro) but not vec (module)" at the current moment?

3

The prelude module could import the vec! macro, via some re-export path, from the module that defines it rather than the crate root. Hm. But there is no actual such export path currently existing, because there is no “alloc prelude”. I don't know if there's a clean solution. Can re-exports be unstable?

(I do think it would be nice if there was syntax to express this directly in use, but that would be a separate proposal so I'd like to not block this on that.)

4

I did an ACP (API Change Proposal) to do this a while back, and it was resolved/accepted as "we'd accept a PR for this," even for the existing preludes.

We do now have the capability for certain paths to be unstable but contain stable items not stably usable at that location.

5

It turns out that this isn't actually possible: macros that have been #[macro_export]ed must be imported from the crate root only. This affects panic! and vec!. That's unfortunate, because vec! is the macro that I most wanted this to be done for. Any ideas for how to solve this problem?

6

Quick initial thoughts:

  • remove #[macro_export] and re-export from root
  • create a new macro that calls the old one
7

A number of std macros are defined using macro syntax with #[rustc_semitransparent_macro] to get macro_rules! hygiene. vec! can be switched to do so. Alternatively, it can be pub used from a location it is #[macro_use] visible and imported from there.

8

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.