No `const fn` in traits - any benefit to an `#[inline]` call workaround?

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 fns 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.)

const fn is used for const evaluation only. It is not used for optimization in any manner. That's not to say that won't be the case in the future. However, some values are promoted to constants (nb: not const fn), which the compiler can then use to eliminate branches and whatnot.

Ahh, so just the nature of matching against a const Option<usize> is all that would be required to avoid the branch?

I got too far ahead of myself in my reading of [Constant Evaluation - The Rust Reference] and didn't read far enough to find the caveat that it only works "when called from a const context"...

If by const Option<usize> you mean const FOO: Option<usize> = bar; (or something promoted to a constant), then it is more than likely that a match on FOO would be optimized out regardless of context.

Ultimately the best way to know if something is optimized out is to check the resulting assembly.

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.