Open notgull opened 1 year ago
If we made this optional, this crate could be used in no_std environments.
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?
In addition, it may also be a good idea to also eliminate the dependency on liballoc. Right now String is used in Key, 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.
Wouldn't make that the crate more complicated to use in general? I'm not convinced that the allocation has a measurable performance impact.
What is your use-case for this crate in a no_std environment?
I'm creating an experimental lightweight no_std
toolkit, where the library is welded directly to winuser or libxcb without the standard library being involved.
What is your use-case for this crate in a no_std environment?
I'm creating an experimental lightweight
no_std
toolkit, where the library is welded directly to winuser or libxcb without the standard library being involved.
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.