I'm running into a compile error using an Array2uom::si::f64::Length from inside an async function.
Please note this did work with ndarray v0.16.
- rust 1.98.1
- uom v0.38
- ndarray v0.17.2 (NOTE - v0.16 seems to work)
The problem can be isolated into the following minimal example, which I would expect to compile:
use uom::si::f64::Length;
use uom::ConstZero;
use ndarray::Array2;
fn assert_send<T: Send>(_t: T) {}
fn main() {
assert_send(check());
}
async fn check() {
let lengths: Array2<Length> = Array2::from_elem((2, 3), Length::ZERO);
std::future::pending::<()>().await;
println!("{}", lengths[(0, 0)].get::<uom::si::length::meter>());
}
This produces the following compiler error message:
error[E0308]: mismatched types
--> src/main.rs:8:5
|
8 | assert_send(check());
| ^^^^^^^^^^^^^^^^^^^^ one type is more general than the other
|
= note: expected struct `Quantity<..., ..., f64>`
found struct `Quantity<..., ..., f64>`
note: the lifetime requirement is introduced here
--> src/main.rs:5:19
|
5 | fn assert_send<T: Send>(_t: T) {}
| ^^^^
Since it is not clear to me if the problem is on the ndarray or the rustc side I also reported it to rust-lang/rust (#162558).
I have a workaround wrapping the Array2 into a newtype with a at(&self,usize,usize)->Length fn and using that to obtain Length quantities inside the async fn. This comes from a bigger project though (https://github.com/ODIN-fire/odin-rs) where such workarounds are clearly suboptimal since it is highly async.
I'm running into a compile error using an Array2uom::si::f64::Length from inside an async function.
Please note this did work with ndarray v0.16.
The problem can be isolated into the following minimal example, which I would expect to compile:
This produces the following compiler error message:
Since it is not clear to me if the problem is on the ndarray or the rustc side I also reported it to rust-lang/rust (#162558).
I have a workaround wrapping the Array2 into a newtype with a at(&self,usize,usize)->Length fn and using that to obtain Length quantities inside the async fn. This comes from a bigger project though (https://github.com/ODIN-fire/odin-rs) where such workarounds are clearly suboptimal since it is highly async.