I forgot the translation had been approved when I answered you. However, once a translation has been approved it's a bad idea to change its design, unless there is an objective issue with it, because it invalidates all the submitted solutions.

Hi. Thanks for the review.
Here is my answer:

• I hesitated to choose bool as type. The problem is the description refers to 1 and 0, and there is no equivalency in Rust between boolean and integers, so it would actually change the problem. Moreover at the time of printing stuff (for example when a test fails), it is visually very ugly if we display booleans, this would require a conversion, extra explanations to the user, etc. All this moves away from the task as it is described, so I prefer to avoid it. Note that among current languages, only C uses bool (which fully is justified IMO: in C, 1 is true and 0 is false).
• When I began to make Rust translation, I also had the tendancy to use usize as soone as it refered to the count of something, like you are doing here I guess. Then some experienced users made me notice that usize are just platform dependent numbers, I searched for documentation, examples, explanation and indeed, I believe it is not suited in general. Does it make a sense here to consider n is in a way platform dependent? We are talking about the number of moves in a game, why would this depend on the architecture? You can see I don't need to cast usize in my solution. If a user needs to use it at usize, it's easy to cast it. Now I almost never use usize in parameter or output types, one rare exception is when it is refering explicitly to indices (in this case it makes sense).
• For the datatypes, I just use the common data types for the language, that are the ones used in most katas and in all other languages. Vec is the basic variable sized container. In all katas I can remember, when you are passed an array as input and you are supposed to return a similar data structure after doing the task, you must return a vector. Once again: if users want to use a deque a hashmap or some other map (seriously???), they are free to do it, but those are uncommon data structures, they require imports..., this gets away from the description and from what is done in other languges, I won't use them. For example, I have solved many katas in Python, and I cannot remember a single one where one is passed in or is supposed to return a deque. At first you provide a list (the basic data structure container), at the end you must return a list. Intermediary steps are the choice of user. What you prefer because it is easier to use is one thing, what the kata is asking is something else.

For the 4th point, AFAIK this is what is done in all katas in Rust (I know one exception, and it is justified). I just stuck with it, just like with the rest.

You idea to implememt impl IntoIterator<Item=bool> is interesting, I believe it is more idiomatic, but once again, this takes us away from the kata itself as it is explained in the description and what we have in other languages. And it is relatively advanced stuff IMO. Look at the description and the detailed example at the end:

• from the list [1] and iterating 5 times:
• [0, 1, 0]
• [1, 1, 1]
• ... the result will be [1, 1, 0, 1, 1, 1, 1, 0, 1, 1, 1]

This is the task as it is explained in the description. I just tried to implement it in the most straightforward and generic way. It is clear there is no point in returning some kind of map here. It's a bad idea to arbitrarily diverge from the task as it is presented, just because personnally you would do it this way or you would prefer this, or because it could be more idiomatic to do it this way in particular language. The concrete implementation of the algorithm, the intermediate datatypes, are left to the user; but the function itself must be the most generic to match with the task as it is described in the kata.

Sure. And I also saw that, though you are only at a 5 kyu ranking at the moment, you solved some not easy and interesting katas, and you seem comfortable with Rust, Haskell, Prolog, and... Coq. Which is not common!

As I mentionned it above, ideally nonetheless, a good review should imply that the reviewer wrote a correct solution on his own in the new language.

I don't know if you can do it at your level, but maybe you can fork the translation (fork button at the top page) and try to write a new solution to check it if you're interested in it? That's what I always do when I review a new translation.

If you reviewed it correctly (tests design + you have an own solution that matches them), let me know and I can approve it myself.

Ah, yes, I have heard of it. I didn’t know how exactly it worked though. Thanks!