Some `Debug` and `Display` impls are hidden behind the `std` feature
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 274
- Forks
- 72
- PR merge metrics
- No merged PRs in 30d
Description
I found out that a lot of Debug and Display impls are gated by std feature (e.g. here, here, and in many other different places). I'm wondering was it done on purpose or just by a mistake?
Those traits are useful in no_std crates. For example, I'm using your library in no_std environment and I'm not able to do things like:
fn error_to_string<T, E>(error: TrieError<T, E>) -> String {
error.to_string()
}
I'd appreciate any comment on that.
Also I'm ready to help cleaning up the no_std support in all the crates to get rid of "hacky" solutions with rstd and to make it look more "sound". Does it sound reasonable to you?
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by inspecting the std-gated implementations in trie-db/src/lib.rs and trie-db/src/node.rs, then trace the related no_std and rstd usage across the crates. Done means the relevant Debug and Display implementations are available in no_std contexts and the broader no_std support no longer relies on the described hacky solutions.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- backend
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100