You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems to me that this project deserves to be a no-std crate by default. From what I can gather, only a few things rely on alloc (see also #220 ), with no reliance on the standard library, at least when it comes to the core-concepts being dealt with.
In terms of just HList, the only non-core items I came across is the into-vec implementation, and that should probably be updated to alloc-gated per #220
Is it worth being no-std first and foremost to maximize compatibility, adding no-std to the cargo-toml keyword list, etc.?
The text was updated successfully, but these errors were encountered:
It seems to me that this project deserves to be a no-std crate by default. From what I can gather, only a few things rely on
alloc
(see also #220 ), with no reliance on the standard library, at least when it comes to the core-concepts being dealt with.In terms of just
HList
, the only non-core items I came across is the into-vec implementation, and that should probably be updated toalloc
-gated per #220Is it worth being
no-std
first and foremost to maximize compatibility, addingno-std
to the cargo-toml keyword list, etc.?The text was updated successfully, but these errors were encountered: