I've updated Rust and cleaned this up:

• Solution accepts slices instead of borrowed vectors
• Updated rand crate use
• Avoid using use super::* at the top level of tests
• Ordered tests in the main test suite

and publishsed

Nah, it overflows easily, if input is more than 46_340 it will overflow.

with the other one you can handle numbers up to 65_535

Ideally you'd skip the square and do the division first (on whichever factor is even) to lower the chance of overflow. I was wondering why there is no test for this.

The gotcha with this is if you get a negative number.

This one has constant comlexity O(1), while an iterator will have at least linear complexity O(n).
While this doesn't make this automatically more efficient for small values, we can optimise this solution by using bit operation for deviding but the compiler already does that for us.
So that means this solutuon needs 4 arthmic operations to execute, while the iterator solution needs at least n arethmic operations, meaning that if n is bigger than 4 the iterator solution is already worse.

Damn man you are good

please use the spoiler flag when posting anything related to the solution

Rejected for lack of random tests to avoid accidental approval, after 15 months without answer. Please publish a new fork with correct tests.

Yup that one should be best practice

I feel this one more performant for very large n, under the assumption that sum() function for iterators goes through n elements.

Good use of bit shifting