cbor icon indicating copy to clipboard operation
cbor copied to clipboard

Allow enabling `serde/std` without also requiring `serde_cbor/std` to be enabled

Open kylefleming opened this issue 5 years ago • 3 comments

Currently serde_cbor's std feature must be enabled if serde/std is also enabled, even if serde/std is enabled separately by another crate somewhere else in the dependency tree.

However, this doesn't necessarily need to be the case. serde provides a StdError type in order to get around this (see https://github.com/serde-rs/serde/pull/1620). This is a type provided by serde as a re-export of std::error::Error when serde/std is enabled and as an export of a custom serde::std_error::Error type with the same interface as std::error::Error when serde/std is not enabled. By conforming to serde::ser::StdError instead of std::error::Error, serde_cbor can rely on the std/no_std state of serde rather than requiring that both libraries' std feature be either both enabled or both disabled.

This allows serde_cbor to be in no_std even if serde/std is enabled. While this might not make a ton of sense at first glance, this change would lead to a much more robust dependency mechanism when serde and serde_cbor are involved, by allowing a crate to depend on serde_cbor with default features disabled and not have to worry if another crate (maybe even higher up in the dependency graph) enables serde/std completely independently. Ideally, the ultimate goal is that features are additive and not dependent on the state of other features laterally in the dependency graph.

This PR does 2 things:

  • Changes the type of the std error that serde_cbor::Error conforms to from std::error::Error to serde::ser::StdError.
  • Adds a line to .travis.yml to test building with serde/std enabled and serde_cbor's default features disabled in order to test that this configuration is buildable.

kylefleming avatar Jun 19 '20 01:06 kylefleming

I'm not sure who's in charge atm for merging in this repo. But I think this is a good change.

stevenroose avatar Jul 12 '20 11:07 stevenroose

it seems that only @pyfisch has admin rights

rjwalters avatar Jul 16 '20 18:07 rjwalters

This was auto-closed completely unintentionally.

kylefleming avatar Sep 14 '20 19:09 kylefleming