Very nice! (Of course I think so as it's almost identical to mine :)

Just one note - You can avoid the reallocation of a new string when you reinsert the name by capturing the return from new_leaderboard.remove(i). It returns the removed element, so you can just take that and stick it back in at the new position.

no random tests

No random tests.

There is no reason why the input string could not include duplicate characters.

Thanks for the feedback.

Modified random test range to 1..=100 for x and 1..=20 for n

I think it's better to use the suited macro todo!() (or unimplemented!()) in solution set up than a pseudo default return value (that doesn't exist in Rust).

Agree, changed to todo!()

Thanks for the fork. Looks nice.

It's a detail that doesn't matter much, but I notice that it seems that all languages (except maybe NASM, I can't understand the tests...) use the same range for inputs and outputs: x in (1..=100) and n in (1..=20). It's better to maintain coherency across languages when there is no particular reason or constraints (there is no performance involved here and all valid codes, and only them, should pass the test).

Another detail, but it's really not a reason for blocking approval: I think it's better to use the suited macro todo!() (or unimplemented!()) in solution set up than a pseudo default return value (that doesn't exist in Rust).

Please update to the current version and use the new framework for the tests.

This translation needs to be rewritten in great part. Random tests time out in Rust 1.62. It's better to use the standard test framework like on almost all other katas. Also, it's preferible to add clear assertion messages, this kata is aimed to beginners.

• No random tests
• Input type should be &str
• It's better to have custom assertion messages giving the input and making clear what is left and right; see for example there how it can be done
• I think it's better to import explicitly the user's solution: use super::to_weird_case

Please fix mispelling in description too. Also update to the latest version.

Eventually rejected. No answer from the author, and bad testcases.

Isnt this overkill for a simple problem?

the minor differences b/w my solution and yours were some big lessons for me!

I consider the 2nd and 3rd bullet points of my comment are indispensable for a translation to be accepted. Using a fixed predefined length for strings could allow many incorrect solutions to pass, it is not acceptable IMO.

thanks; I changed the solution to use u8 as well.
also updated to 1.56