Consider being #![no-std] (and having a default std feature).

[sebcrozet]

See the suggestion on reddit.
This would be particularly useful for embedded applications.

[hannobraun]

Please note that from what I've picked up, having a Cargo feature that conditionally activates #![no_std] is considered bad practice. Rather, a library should do the opposite: Have a feature that opts into using std, and possibly enabling that feature by default.

Here's a Reddit discussion I found on the topic: https://www.reddit.com/r/rust/comments/52owe0/slog_supports_no_std_should_you_opt_into_stdlib/

[sebcrozet]

It seems that some of our dependencies still use std. In particular the num-trait crate of rust-num/num#216. I guess it would be useless to support #[no_std] as long as our dependencies don't…

[tekjar]

Hi. Any new developments on this?

[sebcrozet]

@tekjar It seems the 0.2 version of num-traits now supports #[no-std] so I'll see tomorrow if we can make some progress with that. It seems that a version of num-complex supporting #[no-std] is still not available though.

[sebcrozet]

I've made the necessary on that PR so most of nalgebra can be used without libstd. The main caveats are:

• Anything that require allocations like DVector and DMatrix won't be available unless the user activates the alloc feature which links to the alloc crate.
• Anything that use a trigonometric function will not be usable unless the user provides his own implementation of the functions involved. This means for example that using Convex::new(angle) will trigger an error at link-time because the symbols alga_cos_f32, alga_sin_f32 cannot be found. Providing the implementations like the following (written anywhere in the source of the binary being compiled) will fix the errors:

#[no_mangle]
pub fn alga_cos_f32(data: f32) -> f32 {
   ...
}
#[no_mangle]
pub fn alga_sin_f32(data: f32) -> f32 {
   ...
}

This works that way so the user still has a chance to benefit from quaternions, rotations, etc. even with #![no_std] (because libstd does not provide cos, sin, etc., implementations since the rely on compiler intrinsic and C implementions).

Right now I can't merge this PR though since it depends on the version 0.2 of num-complex which is not yet released.

[tekjar]

Wow that was super quick. Thanks a lot :).

[sebcrozet]

Alright, this is now published on the version 0.15. A page has been added to the user guide to provide some details.