Also quick correction: I meant to say "the false assumption that one byte is always one code point"

Benchmark (old vs. new):

running 2 tests
test test::bench_iter  ... bench:     223,258 ns/iter (+/- 4,671)
test test::bench_slice ... bench:      33,873 ns/iter (+/- 640)

Edit: actually this solution is asymptotically faster. The larger the input, the greater the difference.

I'm afraid you are correct. My new solution using your idea is asymptotically faster.

Lol I don't blame you. It is very confusing, even to myself when I'm trying to understand what I wrote a year ago.

I would never write this kind of code for production. What happens on CodeWars stays on CodeWars or something, I guess.

Rust is a language that’s very adamant that its users write properly idiomatic code, and for a good reason. So it’s not just a matter of personal opinion.

One of the primary design objectives of Rust is its safety, for which the Option and Result types are integral pillars toward this goal. Those two are specifically designed for cases like this where returning an arbitrary value (-1) is ambiguous. If the consumer of this method does not guard against -1 (which we cannot guarantee), it will result in UB which should NEVER occur in safe Rust. If we use Option instead, the compiler would be able to guarantee correct usage by the consumer.

In fact, since Rust programmers expect safety checks like this from the compiler, un-idiomatic code is especially bad because when a programmer does not see Option or Result in the type, they are very likely simply going to assume that the values are already sanitised (I know because I will), which is no fault of their own because the entire “ecosystem” is built this way. To put it bluntly, not respecting Rust’s insistence on idiomaticity would risk undermining its greatest strength, which is that it offloads much of the safety check from the user to the compiler. If so we might as well go back to writing C.

I had the debugging line because I was in the middle of trying to debug the weird Cannot sample empty range error, when it automagically passed. I presume it's a problem with the random test.

Same. I was in the middle of trying to debug this issue, when it just passed the test randomly without any changes on my part.

Rust translation is honestly quite bad (or at least, non-idiomatic).

Return type should be Vec<Option<(u32, u32)>> rather than Vec<(i32, i32)> with None mapped to (-1, -1).

For Rust the test case test::correct_size was misspelled as test::coorect_size.

Trivial but kind of funny and ironic.

Question should specify the field we are operating in, i.e. 16 or 32 or 64 or 128 bit int, signed or unsigned.

Also the msg instruction can be worded more clearly. For example,

Each item in the list of arguments is either a register, or a string literal delimited by '. The list should be concatenated and stored as output.

A for effort.

A++ for making any code reviewer facepalm.

Oh no, poisoned by OOP

This is a famous (arguably) math problem so there are proven algorithms already, so just implement faithfully.
This one is simply the non-recursion version of the algorithm on Wikipedia.

It would be funny if instead of asking for how many people remain, you asked for how many stops have passed.

Not sure how many people will get the joke this is referencing...