Enable usage in no_std contexts

[emberian]

Please also publish the new version to crates.io :)

[BurntSushi]

Could you remove the version bump please? I like to do that in a separate commit/tag.

[BurntSushi]

@cmr This broadly looks good. Why did you change the feature from no-std to std? I think that implies a breaking change, which would require a 0.6 release to get this change released. If we stick with the no-std feature (which seems simpler because you don't have to muck with default features?), then I think this change has no breaking changes, yes?

[emberian]

The feature wasn't actually used at all. And the positive form is more
suitable because cargo features are formed from the union of all
features needed by dependencies; if one dep wants to use a std dependent
feature implicitly, but another requires the no std feature, the crate
will be compiled no std, breaking the first crate.

On Mon, May 2, 2016, at 01:49, Andrew Gallant wrote:

@cmr This broadly looks good. Why did you change the feature from no- std to std? I think that implies a breaking change, which would
require a 0.6 release to get this change released. If we stick with
the no-std feature (which seems simpler because you don't have to
muck with default features?), then I think this change has no breaking
changes, yes?

---

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#46 (comment)

cmr
+610481782084
http://octayn.net/

[BurntSushi]

Ah good point!

The feature no-std appears to have been used though? It was guarding the definition of the new module.

[emberian]

Oops, right, it just didn't enable no_std.

[BurntSushi]

Looks great! I'll get a 0.6 release out soon.