With the move of the Error Trait into core, the std flag is no longer needed. #100

Activity

1. daviddrysdale commented on Oct 21, 2024

   

   daviddrysdale

   on Oct 21, 2024

   Contributor

   More actions

   Thanks!

   The code change looks fine, but there would need to be some knock-on effects:

   • Presumably this makes 1.81 the MSRV for the crate? (Currently it's 1.58)
   • Removal of a feature is going to need a major version bump.

   So we'll probably wait for a while before merging this PR.
2. juliankrieger commented on Oct 21, 2024

   

   juliankrieger

   on Oct 21, 2024

   Last edited by juliankrieger

   Author

   More actions

   There are a couple of strategies you could employ to release this earlier.

   • You could feature gate the trait impl behind a rust-1.81 feature
   • You could feature gate the trait impl behind a v.1.81 specific feature from https://crates.io/crates/rustversion
   • Re-export the Error Trait and change the MRSV to 1.81 only for no_std environments
   • Introduce a rustc flag similar to anyhow (see core::error, no_std dtolnay/thiserror#304 (comment))

   Meanwhile, you could avoid breaking changes by keeping the std feature in the crate, but not apply any cfg attributes that depend on it. I actually use this strategy for all my no_std-by-default crates so that I can avoid a breaking change in the future if I need something from std.

   Of course, waiting for Rust v.1.81 to mature is a fine strategy as well. With https://github.com/esp-rs/rust being the only active Rust fork I know also recently hitting 1.81, I would be very interested in hearing your opinion on why keeping the MRSV that low is useful!

   👍React with 👍2Reacted by Benjamin Brienen and Paul Crowley
3. juliankrieger commented on Sep 29, 2025

   

   juliankrieger

   on Sep 29, 2025

   Last edited by juliankrieger

   Author

   More actions

   @daviddrysdale With my Issue/PR now being almost a year old, maybe we could open this discussion again? :) With 1.90.0 hitting stable, do you think it would be worth it to reconsider? You could also consider just keeping the std feature but using core impl's anyway. Sure, this makes consuming the crate a bit confusing, but It won't break no_std environments this way :)
4. daviddrysdale commented on Jan 14, 2026

   

   daviddrysdale

   on Jan 14, 2026

   Contributor

   More actions

   Fixed with #120
5. daviddrysdale

   closed this as completedon Jan 14, 2026