Suggestion for guidelines around std cargo features

[tarcieri]

I have a suggestion for a slight modification to an example given here:

https://rust-lang-nursery.github.io/api-guidelines/naming.html#feature-names-are-free-of-placeholder-words-c-feature

Namely in regard to this:

// In lib.rs

#![cfg_attr(not(feature = "std"), no_std)]

I would suggest the following instead:

// In lib.rs

#![no_std]

#[cfg(feature = "std")]
extern crate std;

(Note: I'm well aware of efforts to eradicate extern crate. If use std worked here, I'd suggest that instead)

The reasons for using the latter form:

• Consistently imports core (it seems newer Rust versions always import core)
• Purely additive - no double negative (i.e. if not std then no_std), and generally just easier to tell at a glance what's going on
• More adaptable to scenarios where you may want alloc and std traits, but want to always consistently get the macros from one or the other

[elichai]

But then how do you abstract over it?
i.e. what people usually do is:

#![cfg_attr(not(feature = "std"), no_std)]

#[cfg(feature = "std")]
#[macro_use]
extern crate std as core;

use core::slice;

[tarcieri]

Let me start by saying how to import libcore appears to be moot now, as at some point (possibly the 2018 edition) it's imported by default regardless of if no_std is used. TIL.

That said, that style seems popular among people adding no_std support as an afterthought, but highlights exactly the sort of concerns I'm raising: this approach inconsistently imports core. Crates using that style are the ones I most frequently find broken when trying to use them in no_std environments. I would consider that approach both an antipattern and obsolete.

This is because std is masquerading as core, and in my experience that blows up when people aren't testing no_std (and combinations of no_std and other cargo features) properly. The result is people using functionality only available in std via a masqueraded core by mistake (not everyone has an encyclopedic knowledge of what parts of std are in core or bothers to check), which breaks as soon as the std feature is disabled and you try to use libraries like this in these environments.

In my experience there are a mixture of styles for gating no_std. Embedded Rust developers almost exclusively choose the straightforward #![no_std] approach I proposed for their crates, even when these crates have optional alloc or std-dependent features.

There's a good reason for that: it gives you a common baseline. no_std has a little bit of spooky action at a distance (less so if core is ubiquitously available). Cargo features are supposed to be purely additive, and #![cfg_attr(not(feature = "std"), no_std)] is a double negative which is toggling on a different behavior profile based on the absence of a Cargo feature, which to me seems backwards. By always doing #![no_std], it means you start your crate at a consistent starting place, then add functionality from there as you add Cargo features, rather than trying to use Cargo features to optionally subtract functionality.