-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for databake
, writeable
, zerovec
traits?
#183
Comments
writeable
and zerovec
traits?databake
, writeable
, zerovec
traits?
Separate from anything else, yeah, this is probably a hard blocker. |
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 |
I typed this comment out in #182 but realized it would be better here: The #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 #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. :-) |
The
bstr
crate has an optional dependency onserde
to add Serialize/Deserialize impls.Would you accept a pull request adding implementations of the following traits behind optional, non-default features?
Both of these crates live in the
icu4x
repository but are intended to be used outside the context of icu4x.I believe
bstr
depending ondatabake
,writeable
, andzerovec
is the correct direction:bstr
defines a concrete type that implements the traits exported fromdatabake
,writeable
, andzerovec
, 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 ofzerovec
andwriteable
.CC @Manishearth @hsivonen
The text was updated successfully, but these errors were encountered: