thanks for the feedback!

I think using the language's built in functions should be allowed. The python solution allows it's itertools permutations function as well.

I would also like to compliment you on your translation of this Kata. This is very clean, well implemented, and correct as far as I can tell.

Please reach out to me on linkedin https://il.linkedin.com/in/michaelsalaverry

Moved tests use statements to tests module. In the unlikely event of a user solution using rand::thread_rng or rand::seq::SliceRandom there will not be a double import with this change.

IDK... But they are already there in the initial solution. It may me more complicated in this respect, but in this case a subset of input is returned, while the version with String requires understanding the difference between str and String.

I am not sure lifecycles are appropriate in an 8 kyu exercise

I'm not sure which version is better for educational purposes without a broader context, so I'll just leave it here and let someone else choose.

thanks for checking my work.
I fixed the extra ')' and updated to Rust 1.44

looks good to me

We should definitely use this fork over mine!

This fork doesn't use the Rust 1.44. You have to select it from the dropdown menu when editing the Kata and select it again when saving/publishing the Kata. Otherwise it won't remember the language version change.

I've not used quickcheck before, but I inserted a print statement and found out that the quickcheck random test can test for 0.

As you have pointed out, the description reads "Assume both x and n will be positive numbers greater than 0."

Your description reads:

count_by(1, 10) // should return vec![1,2,3,4,5,6,7,8,9,10]
count_by(2,5) // should return vec![2,4,6,8,10])
                                               ^
                                               extra ) there

looks good to me, but there is something we should both change.

The description says, "Assume both x and n will be positive numbers greater than 0."

Both of our implementations say x and n are i32, when they should be u32 instead. We don't want quickcheck to input negative numbers for x and n, which it will do as the function signature is currently implemented

Bump Rust version,
Add spaces here and there,
Change one x..y+1 to x..=y,

LOL, keep it simple

thanks for noticing, I fixed my misspelling.

please use username0's translation fork