std::iter::once(value).cycle() is better expressed as std::iter::repeat(value)

rules lawyer

the tower of babel

Not only is 2kB an insignificant amount of memory to use for this, but also you already have that memory available. On most systems, the default stack size for the main thread is 2MB. Unless the rest of your program is using 99.9% of its available stack, it costs almost nothing to dedicate 2kB of stack to make this array, and pop it from the stack after this function finishes.

As for heap allocation, I'm not very familiar with Rust's allocator, but it's quite possible that creating a hash map for this will in some cases be forced to take 4kB, since most operating systems think about memory in 4kB chunks.

I cannot understand which function has been call, i check the docs but it seems haven't a kind of i32::max() function there.

Is it using the Iterator::max ? Returns the maximum element of an iterator. seems not fit which this situation.

thks for any help

The best and the clearest to understand solution

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.

You outsmarted me :0 congrats :)

This is no real assembly, just follow the description: why should we care about the registers size? And without any precision it is clear that you are not expected to operate on unsigned integers. About the rewording, this is at most a suggestion, not an issue.

What does it change here?

This solution is going to be invalidated because the kata will be changed to use more suited unsigned types. I let you know so you may want to submit a new mended version.