Consider making format no_std-compatible

[MarcusGrass]

Hi,

I've got the suggestion above. Maybe I'm the only person who has this weird fixation with doing stuff no_std that definitely could be using std, but I'll feel it out.

Looking at the code:

Option 1: Change the parameter type from impl io::Write to impl core::fmt::Write

This has the negative side-effect (apart from the major bump) of disallowing many kinds of buffers that implement the former but not the latter.

Option 2 Separate impl for core::fmt::Write

Would cause a bit of code-bloat but could probably by joined pretty well, spontaneously I think that std::io::Write must be a superset of core::fmt::Write so maybe it could share some implementation.

Option 3 Feature gate the trait used on std

Has possible surprising behaviour when suddently the trait bounds change on a feature switch which may or may not happen through feature unification.

If there's interest in any of these solutions (or others) I could likely find the time to implement them, there could also be some part of the code that I'm missing that keeps this from being implemented for some other reason.

All of the above are are breaking changes since the Format-error contains a std::io::Error which would need to be remove regardless of options.

Then again, if the format feature only works on std, so if the change is feature-gated on std maybe that's not really breaking? Not sure how to think about that.

[jhpratt]

• Option 1 is a breaking change, so it would be tracked by Breaking change wish-list #650. It is plausible that this happens, but far from certain.
• Option 2 is the only option for the 0.3 series of time. It was attempted in Add backwards compatible support for fmt::Write #407, which I ultimately closed for the reasons stated within.
• Option 3 is incompatible with how cargo feature flags are supposed to work, so it's a non-starter in any version.

Ultimately this is a complex problem with no easy solution. Right now my plan is to wait for specialization (to the extent necessary to solve this problem) or make a swap in a future breaking change. The latter may not happen, though, given forward compatibility with specialization between the two traits.

[MarcusGrass]

Ah I see, thanks for having a look, it's fairly trivial to implement some basic formatting with just access to the no_std-structs manually, and the default display does the job most of the time