stadiamaps / stadiamaps/ferrostar
[core] no_std support
- Dominant language
- Kotlin
- Stars
- 419
- Forks
- 81
- Avg merge
- 6d 1h
- Merged PRs (30d)
- 7
Description
At some point we'll want to explore support for no_std platforms. Our initial focus is on major mobile operating systems, which have support for the full standard library, but certain embedded platforms we may target in the future may not.
This issue tracks known steps we'll need to take to support no_std:
- [ ] non-UniFFI interface: UniFFI requires the standard library, particularly making use of things like `std::sync::Arc` in constructors, and types like `std::time::SystemTime` for mapping timestamps.
- [x] We use `std::collections::HashMap` a few places; could probably replace with `alloc::collections::BTreeMap`; we can also use `Vec` from `alloc`
- [x] `NavigationController` currently uses a `Mutex` for internal state mutation. This is arguably an antipattern and breaks the clean "functional core / imperative shell" pattern. We should probably rearchitect this to return a new controller state (which must be saved by the caller) before v1.0.
- [ ] Upstream changes to `thiserror` to support no_std: https://github.com/dtolnay/thiserror/pull/304
Contributor guide
Assessment
This issue has not been assessed yet.