Short question - does calling an #[inline] const fn
within a trait method effectively extend any of the benefits of a const fn
? (e.g. compile time evaluation of if
/match
, though the trait method can't have const
status, thus ending any further compile-time checking...)
Longer explanation -
I'm looking at using traits with associated constants to avoid associated types, thus hopefully avoiding incompatibilities of MyTrait<Vectors = Vector3/4/5/6, Matrices = Matrix3/4/5/6>
. Ultimately I still want generic type-level control over vector/matrix sizes and hopefully to maximize the compile-time guarantees of the concrete types being built up, but I'm just exploring options to see how they work for now.
I've mocked up a working concept [playground]. In the process I realized I would like to avoid the match arm binding check by making it a constant function, but those are not allowed in traits. So, I just made the const fn
s elsewhere and #[inline]
ed them into the trait methods.
Clearly it works... But, I guess I'm wondering if this provides the benefit I think it might? Or, if I'm just building up a lot of framework that'll fail to come together somewhere further down the line? Any thoughts on this would be greatly appreciated!
(It might also be worth mentioning that I'm hoping to make this work for general kinematic and quasi-static simulations. And options for quasi-static orientation solving are a viable simplification in the kinematic forms, so position vectors of DOF4/5 combined with velocity/acceleration vectors of DOF3 are perfectly viable, and again, would cause crazy amounts of associated types to differentiate.)