-
Notifications
You must be signed in to change notification settings - Fork 9
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
Make this crate no_std
#17
Comments
This crate is primarily used by servo and high-level GUI tool-kits. Both depend on the standard library. What is your use-case for this crate in a no_std environment?
Wouldn't make that the crate more complicated to use in general? I'm not convinced that the allocation has a measurable performance impact. |
I'm creating an experimental lightweight |
Ok. I personally don't think that GUI applications gain much from avoiding the standard library. When your toolkit reaches the point where its used in applications I will reevaluate if keyboard-types should support operation without std. Then I might merge your patch. |
This crate currently relies on
libstd
; however, I'd like to use this in ano_std
program. Looking through the source code, it looks like the onlystd
-exclusive import this uses (without additional features) isError
. If we made this optional, this crate could be used inno_std
environments. This would be a breaking change.In addition, it may also be a good idea to also eliminate the dependency on
liballoc
. Right nowString
is used inKey
, but it may be replaced by an&'a str
in order to allow usage on platforms without allocators and eliminate a potential allocation from the crate.I will implement this PR if the behavior is desired.
The text was updated successfully, but these errors were encountered: