vcombey / fallible_collections

impl fallible collections in rust, quite as describe in RFC 2116
Apache License 2.0
33 stars 14 forks source link

Support stable rust #1

Closed baumanj closed 4 years ago

baumanj commented 4 years ago

Currently the crate depends on a number of experimental features. In order to allow the use of the crate in stable environments, it should be possible to conditionally implement the interfaces locally (or import implementations from other crates such as hashbrown's try_reserve.

Supporting stable rust is a prerequisite for using this crate to address issues like https://bugzilla.mozilla.org/show_bug.cgi?id=1624698.

I don't have much experience with using unstable features conditionally, but the best solution I've found so far is adding a feature to the crate like:

[features]
unstable = []

Then conditionally enabling the experimental feature like so:

#![cfg_attr(feature = "unstable", feature(try_reserve))]
…
#[cfg(feature = "unstable")]
use alloc::collections::TryReserveError;
#[cfg(not(feature = "unstable"))]
use hashbrown::CollectionAllocErr as TryReserveError;

Using something like rustversion seemed like a promising option to avoid the need for an explicit feature on the crate:

#![rustversion::attr(nightly, feature(try_reserve))]
…
#[rustversion::nightly]
use alloc::collections::TryReserveError;
#[rustversion::not(nightly)]
use hashbrown::CollectionAllocErr as TryReserveError;

But non-builtin inner attributes are unstable, so I don't think there's a way to enable experimental features like try_reserve automatically when building with a nightly compiler. Perhaps it would be possible with a custom build script to detect the compiler version and cargo:rustc-cfg, but that seems like more complication than necessary.

I'm interested to hear any thought you have about the approach, and if using a feature added to the crate, whether "unstable" would be a good name.