using string as a parameter name is bad practice because it overwrites the string module

Ah, we've gone full circle now.

Interesting, thanks, we'll have to look at that with a benchmark.

It doesn't seem to be bad at all. There are always nitpicks like an unecessary .to_string() before parsing and type hint that would have been inferred, but it looks like pretty standard Rust code.

Though I do wonder, if you wanted to write a Perl solution, why not fork it in that language directly?

Thanks, I'm really not very good at Rust as you can probably tell.

Just so you know, the purpose of .expect("text goes here") is to provide context if the unwrap panics. If you don't feel the need to provide context, a simple .unwrap() makes more sense.

I'm currently learning programming, and writing random tests is part of my practice to understand different testing techniques.

the description says

Kumite (ko͞omiˌtā) is the practice of taking techniques learned from Kata and applying them through the act of freestyle sparring.

It's all part of my learning journey. Thank you for your insights!

I've been wondering, do you think random tests are helpful in kumites? It looks like asserting the equality of two implementations, which only works when the reference is known to be definitely correct (in which case, why not use it in the first place instead of doing testing?).

Or maybe you're writing them just for practice, I don't know.

add random test

It's a good implementation, but by nature converting a number into a string is much more complicated than a simple while loop which runs a dozen or so times.

Because sentinal values are a bad idea for many reasons, though you probably already learned this in the 4 years since.

However I'm still bamboozeled as to why it returns Option<Vec<i32>> as opposed to Option<[i32; 3]>. This isn't an arbitrary list, it's exactly 3 elements. I might even expect Option<(i32, i32, i32).

Mind clarifying? Rust implicitly returns the last expression in a function body if that's what you were wondering.

not return

Seems like the more readable the code gets, the worse it performs.

It's probably because of all the references and function calls.