You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I tried to give that a spin here using num-traits constrained generics but it ended up in one difficult spot: When T can be anything, the automatically implemented commutative implementations for Mul and Add fail, particularly with Duration:
impl<T: num_trait::Float> Mul<T> for Duration and impl<T: num_trait::Float> Mul<Duration> for T cannot coexist because a user of the create may implement num_trait::Float for Duration, leading to a conflicting trait implementation. That's blocked by RFC 1210.
Resolving this by making operations non-commutative could work, but then the specializations for f64 would have to be implemented manually.
I also thought of feature-gating the implementation, defaulting to <f64> specializations if generic types are not wished for - that's a bridge to be crossed once I'm there.
Is it possible to make something like
Mass<T=f64>
instead of justMass
?For example, I would like to work with f32 precision mass, volume, etc...
The text was updated successfully, but these errors were encountered: