I wrote a lengthy reply on the main discourse, please refer to that so I don't need to address the same issues twice.

As for a new fork that actually improves the translation regarding assertions and randomness: yes, absolutely! If you manage to implement proper random tests, that would be a huge improvement as well.

For assertions, please refer to this reference kata to see how to create useful, properly formatted assertion messages.

For the random tests: there are currently translations pending in Python and Scala (and perhaps others) that implement random tests, although I have not verified whether they do so correctly or succesfully. Take a look if this helps you.

Final note: if you do end up publishing a new translation, make sure to leave a suggestion linking to it on the kata's discourse, otherwise it is hard to discover.

but a vec of vecs has to follow two pointer inderections.

Yes, but as I mentioned, the performance overhead is negligible in this particular case. There are very few kata where the cost of pointer indirection or cache misses would actually make a noticable difference in solvability.

at the very least you should use a single 1d vec and do some arithmetic to index it properly.

This would break the spec, and is unneccessary complexity in a world where nested arrays/vectors exist and come at virtually no cost (see above).

yeah, technically the test cases as currently written call for this, but i don't think this should be.

You must be new here ;)

While the points you mention are valid, and in a perfect world where everything was strictly idiomatic this kind of thinking would totally be forced into consideration, very few kata actually conform to it. There are lots of reasons for this: author laziness, author ignorance, trying to force a square peg (translation) through a round hole (task authored in another language), avoidance of diverging from existing translations, etc.

Personally, I detest kata where validation is forced on the user for no other reason than the author thought it would be more interesting (It's not. Never is.). However, relating kata to production code is simply a fool's errand; few of the assumptions you could make about input, structure, etc. in production apply here, where the author is free to make up the wildest formats, requirements, edge cases, etc.

If idiomatic code is important to you, I'd suggest directing your efforts at new translations of kata where Rust is not yet an available language. As the translation author, you are free to be as idiomatic as you'd like, as long as this does not entail diverging from specs or uniformity with existing language translations. This would be greatly appreciated, in fact!

As for this kata, it's just not worth the invalidations. Mind you, as I said elsehwere, there are cases where we allow a fork to invalidation dozens or even hundreds of solutions, but usually that's when an actual error is detected, i.e. correctness is at stake. Unidiomatic code isn't really incorrect, merely slightly frustrating for those who know better. Hence my rejection of your fork. I hope you understand.

Cheers.

As mentioned in the discourse, this change isn't sufficiently useful to justify invalidating current solutions.

That said, there are other issues with this translation (bad assertion messages being one of them). Also, I just realized that using const generics means that there can be no random board sizes, since the rng is not const. That's actually a major regression that disqualifies const generics for this (and probably many other) kata.

A vec of vecs is completely fine, so I'm going to reject this translation.

There is no way to do that without invalidating all current solutions. While it is sometimes justified to do so, I wouldn't claim this to be the case here; your proposed change effectively just means "allocate on stack instead of heap", which would have virtually no measurable effect on the actual performance or the required solution. Further, some translations (whether justifiably or not) use jagged matrices (in the sense that some rows are shorter than others). This wouldn't be possible with const sizes.