• Added a few more sample tests covering a wider spectrum of inputs.
• Made random tests use proper random numbers that will not overflow
• Changed assertion output to be as beginner-friendly as possible
• Changed solution setup. It now does not result in a compiler error (which would make this kata unique, since every other kata is required to have the solution setup compile out of the box), and instead produces incorrect values.

Indeed, I should have tested my suggestion before asserting that it actually works.

Anyway, I've forked the translation and changed a few things.

Yeah, I wanted to avoid overflow, but that didn't work. Thanks for catching that.

I've tried your suggestion, but b ended up as 0 or 1 in most cases.

I've also added assertion messages.

Can you explain the logic in the creation of max and min in the random test? To me, it seems like a particularly complicated way of writing 1 and -1, respectively.

If the point is avoiding overflow, I'd simply generated a random i32::MIN < x < i32::MAX, a random a <= x) and b = x / a.

Also, this kata really needs good, clear assertion messages.

Fix

• Add random tests
• Add assertion messages
• Add language specific block in description

Rejected, because:

• No random tests
• No assertion messages
• No language specific block in description

Added rust-specific info to the description.

Rejecting, because:

• The requirement about n<1 or not an integer is a typical relic from authoring in a weakly/none typed language like Python or JS. It makes absolutely no sense in a strongly typed language, where input types can't be arbitrary, nor can they accidentally be negative integers when u32 is chosen. Using u32 and ignoring the input handling, which is completely tangential to the task anyway, was the correct choice here.
• You completely changed the solution used, but this translation was authored by akar, and upon approval the solution will be published in his name; however, it now contains your code, not his. Please don't do that unless strictly necessary. The solution's performance is completely irrelevant (unless it's a reference solution used in test validation) and really not your concern.

No longer an issue.

Thank you for reviewing that.

There is no point in forking a translation just to update the original solution (which would end up published in the original author's name anyway). Especially when there are other things that actually need fixing, e.g. missing assertion messages.

Rejected.

Good catch. Fixed.

Approved

Also made a typo trying to type "typo".

Thanks for updating stale translations. I've approved a downstream fork.

For future reference: unless the reference solution is wrong/buggy or not performant enough, there's no reason to change it with your own in a fork; when the translation is approved, the solution (with your changes!) will show up under the original author's name, not yours. I'm sure you'll understand why it's undesirable to publish code in someone else's name.