Change:
/// /// If the named environment variable is present at compile time, this will /// expand into an expression of type `Option<&'static str>` whose value is <del> /// `Some` of the value of the environment variable. If the environment /// variable is not present, then this will expand to `None`. See /// [`Option<T>`][Option] for more information on this type.  Use /// [`std::env::var`] instead if you want to read the value at runtime. </del> <ins> /// `Some` of the value of the environment variable (a compilation error /// will be emitted if the environment variable is not a valid Unicode /// string). If the environment variable is not present, then this will /// expand to `None`. See [`Option<T>`][Option] for more information on this /// type.  Use [`std::env::var`] instead if you want to read the value at /// runtime. </ins> /// /// [`std::env::var`]: ../std/env/fn.var.html /// <del> /// A compile time error is never emitted when using this macro regardless /// of whether the environment variable is present or not. /// To emit a compile error if the environment variable is not present, /// use the [`env!`] macro instead. </del> <ins> /// A compile time error is only emitted when using this macro if the /// environment variable exists and is not a valid Unicode string. To also /// emit a compile error if the environment variable is not present, use the /// [`env!`] macro instead. </ins> /// /// # Examples ///

Discussion:
I tried this code: compiler with (using Bash shell syntax, any non-Unicode environment variable value for will work). I expected to see this happen: a value, as the currently states "If the named environment variable is present at compile time, this will expand into an expression of type whose value is of the value of the environment variable". Instead, this happened: The program outputted: Currently, the documentation doesn't consider the possibility of a non-Unicode environment variable value (as only Unicode values can be expressed as a &'static str), and the implementation emits , the same as for a non-existent environment variable. There are three possibilities that I can think of: current behaviour is a bug, and a compilation error should be emitted as it isn't possibly to represent a non-Unicode value as a , and the documentation should also be updated to reflect this. Note that this would be a breaking change to the compiler itself, but would be allowed as it would be a bugfix. current behaviour is not a bug, and the documentation should be updated to reflect the current behaviour. as 2, but the behaviour is unexpected enough to warrant a warn/deny-by-default lint. Personally, I believe 1 to be the case, as the current behaviour is unexpected and leads to code patterns like silently returning incorrect results. There doesn't seem to be a "correct" value to return, as is already taken by "does not exist" and cannot represent a non-Unicode value. It seems unlikely anyone is relying on the current behaviour given Rust's very UTF-8 everywhere design, the fact the same result can be achieved much more easily by just not setting the environment variable, and the platform-specific nature of what non-Unicode values can exist (Windows UTF-16 unpaired surrogates vs. Unix invalid UTF-8 bytes). It therefore seems to be more likely to occur when someone has mistyped something in their shell or due to data corruption, which the current output would make rather confusing to track down (as it would seem to say the variable was missing, rather than set incorrectly). : I believe the decision of what to do is down to libs-api, so label +T-libs-api
I've created a draft implementation of option 1 in .