.

Tests are limited to within Int range, which is specified to be at least 29 bits IIRC.

Because outside of a very narrow set of high performace situations, it doesn't matter at all. Even the cheapest embedded computer can do this in nanoseconds. And treating it like strings is more intuitive since the problem cares about them more like strings than numbers.

Currently it works fine.

Fixed

Not an issue: typos are suggestions.

Same :D

Yes, you are right!

I benchmarked this solution and your solution with valgrind, found:

total heap usage: 71 allocs, 71 frees, 9,658 bytes allocated
total heap usage: 20 allocs, 20 frees, 5,959 bytes allocated

• both built with cargo build --release
• run generate_shape(50)

True; that'd be a little more robust.

Also your solution doesn't handle empty words (when there are two or more spaces in row in string)

That's completely false.

However, you are right about the non-ASCII first letters.

With something like
.unwrap_or(String::new())
?

I prefer match for readability and because it scales better for more cases so my default style is to use it. I agree that, for this case, 'if' would be fine.