Make this crate `no_std`

[notgull]

This crate currently relies on libstd; however, I'd like to use this in a no_std program. Looking through the source code, it looks like the only std-exclusive import this uses (without additional features) is Error. If we made this optional, this crate could be used in no_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 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.

I will implement this PR if the behavior is desired.

[pyfisch]

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.

[notgull]

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.

[pyfisch]

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.

[waywardmonkeys]

I have a vocabulary crate for pointer events that I'm working on and it is no_std to keep it widely usable. I want to use Modifiers and such from here, but that would require no_std support here.

I've done a PR #69 to show what I'm thinking, but now I see that it is almost line for line identical with #18, although a bit simpler in one part.

[pyfisch]

cc @madsmtm What do you think about no_std?

[madsmtm]

I don't have strong opinions on #![no_std]. I tend to try to support it in my own crates when I can, since it usually doesn't cost much in terms of maintenance (especially since error_in_core became stable in Rust 1.81, so for crates whose MSRV is higher than that there usually isn't even a difference in the provided API), and it helps with being more explicit about allocations.

[waywardmonkeys]

If the 0.8 release could bump MSRV to 1.81, I could update this PR to always impl Error.

[pyfisch]

@madsmtm Currently winit MSRV is 1.73, but according to policy it would be ok to bump it to 1.81 if this crate declared a MSRV of 1.81, right? (Debian sid is at 1.85 and and the current 1.85 - 3 is greater than 1.81)

https://github.com/rust-windowing/winit?tab=readme-ov-file#msrv-policy

[waywardmonkeys]

In case there is a desire to bump the MSRV, I have submitted PR #70 which does that.

[madsmtm]

Sorry, I guess I wasn't being clear. I don't think keyboard-types should bump it's MSRV for this, I was stating it to note that the support burden for no_std will be less in the future. Instead, I'd probably prefer:

#[cfg(feature = "std")]
use std::error::Error;
#[cfg(not(feature = "std"))]
use core::error::Error;

[waywardmonkeys]

In that case, the no_std wouldn't have the same MSRV as the std ... is that okay with you?

[madsmtm]

I'd be fine with that, yeah.

[madsmtm]

Heard an actual use-case for #![no_std] today from @daxpedda: the wasm32v1-none doesn't have std available, but Winit still want to support that.