Support for `databake`, `writeable`, `zerovec` traits?

[sffc]

The bstr crate has an optional dependency on serde to add Serialize/Deserialize impls.

Would you accept a pull request adding implementations of the following traits behind optional, non-default features?

• databake::Bake
• writeable::Writeable or the soon-to-be-released TryWriteable
• zerovec::ule::VarULE
• zerovec::maps::ZeroMapKV

Both of these crates live in the icu4x repository but are intended to be used outside the context of icu4x.

I believe bstr depending on databake, writeable, and zerovec is the correct direction: bstr defines a concrete type that implements the traits exported from databake, writeable, and zerovec, which implement the traits on standard library types.

One risk of the dependency going in this direction is that we haven't released these crates at 1.0 yet, so the traits may be subject to change, which can make it annoying on the bstr side. We could alternatively consider a dependency going in the other direction, at least to start, and then switch the dependency direction when we reach 1.0 of zerovec and writeable.

CC @Manishearth @hsivonen

[BurntSushi]

One risk of the dependency going in this direction is that we haven't released these crates at 1.0 yet

Separate from anything else, yeah, this is probably a hard blocker. serde is an ecosystem standard and is likely to be at or remain at 1.0 for a very long time. Perhaps forever. I don't think I can say the same about any of the crates you've proposed. Basically, public dependencies (e.g., zerovec) should be at least as conservative (or "mature" or whatever word you want to use) as the dependent (e.g., bstr). bstr is pretty mature at this point, and I have no plans for bstr 2.0. More than that, others are expected to use bstr as a public dependency. This in turn makes my approximate plan "hopefully never release a bstr 1.0." I don't think it has reached widespread use as a public dependency though, so it could probably be done without too much pain. But still, the point is, I really do not want to do any major version changes. And if I take a public dependency on crates that are still evolving, I will effectively be forced to do major version changes at the union of all major version changes of my dependencies. That is a rather severe change from the status quo plan.

[Manishearth]

I'm okay with having an optional dependency on bstr going the other way from those crates, it seems fine especially since those crates change more often

[BurntSushi]

I typed this comment out in #182 but realized it would be better here:

The https://github.com/BurntSushi/bstr/issues/183 issue is harder though. You'll likely need to wind up defining your own type to deal with those cases anyway, in order to get around the orphan rules. So if you're doing that anyway, it might not make sense to also use bstr? Not sure. With that said, bstr is meant to be a public dependency. It's encouraged to impl traits for BString and BStr. So you could convince the crates in https://github.com/BurntSushi/bstr/issues/183 to add a bstr feature. If and when they reach "maturity," I'd be open to flipping that relationship around.

---

Which I think is consistent with what @Manishearth just said. :-)