-
Notifications
You must be signed in to change notification settings - Fork 39
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 #![no_std] without liballoc #58
Comments
This is a stopgap until the issue of Unicode normalization can be properly addressed (e.g. should we check strings are NFC or NFD?) Furthermore, the `unicode-normalization` crate doesn't support `no_std` environments (sans liballoc yet): unicode-rs/unicode-normalization#58 Ensuring all strings are ASCII, while perhaps overly restrictive for now, will ensure all documents produced today are canonical in a way that's forward compatible with canonical Unicode.
tinyvec is necessary because theoretically decompositions and compositions can map to an unbounded number of decomposed # code points. There's probably a small practical limit in what the composition data allows though |
Perhaps |
Sure, PRs welcome. Ideally something that switches between arrayvec and a non panicky variant |
Oh, now I see Elsewhere I use https://docs.rs/veriform/0.1.0/veriform/derive_helpers/trait.TryExtend.html |
I'd like to be able to use
is_nfc_quick()
/is_nfd_quick()
in a context where liballoc isn't available.It looks like the only thing linking
liballoc
right now istinyvec
. Would it be possible to maketinyvec
into an optional dependency?The text was updated successfully, but these errors were encountered: