Rfcs: `env!` for non-string constants

[jmegaffin]

There are some useful environment variables that are or could be non-string values, like CARGO_PKG_VERSION_*, NUM_JOBS, and DEP_*_*. Currently, however, they are only exposed to Rust as constant strings, not numbers, so it is impossible to do something like:

pub const VERSION_MAJOR: usize = env!("CARGO_PKG_VERSION_MAJOR");

You need to parse the string into an integer and then unwrap the result, which are both non-constant operations. If there were env!-like macros for boolean, integral, and fractional values and characters, then it would be possible to use them in new places like constant definitions, patterns, and eventually generics. It is possible to work around this in some cases by defining functions instead that internally parse the string into the desired type and using comparisons instead of pattern matching, but this is not ideal for ergonomics and potentially efficiency.

---

Of course, this would also be satisfied by making the appropriate standard library functions (str::parse, Option::unwrap) const fns, which would work for even user-defined types, but the macro solution could be implemented immediately without having to change any existing APIs. These macros could also be implemented as procedural macros, but support for this feature outside of deriving traits is poor as of the time of writing.

[solson]

Of course, this would also be satisfied by making the appropriate standard library functions (str::parse, Option::unwrap) const fns, which would work for even user-defined types

I glanced at the implementation of parse for integers and it seems likely that Miri-powered constant expressions could handle it. It's going to take a while to iron out all the design and implementation details for that, though.

[Ericson2314]

On a meta note, improved env! + miri is an interesting first case on looking at the division of labor between procedural macros and constant evaluation. Ultimately, only the host platform (of the code being built) / Miri know what a usize is. But parsing the env var into a literal that may or may not overflow can be done on build platform / with proc macros.

[jmegaffin]

But parsing the env var into a literal that may or may not overflow can be done on build platform / with proc macros.

Yes, this is precisely what I mean.

[Centril]

This should simply "fall out of" CTFE improvements so there's nothing special about env! here. Therefore I'll close it since it's not directly actionable.