Ok, but

1. bool is a subclass of int, so its type is bool but it is an instance of int
2. what is the issue and what are you suggesting?

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.

no, my proposed change means "don't use a pointer of pointers". I agree heap vs stack is irrelevant, but a vec of vecs has to follow two pointer inderections. this absolutely can have extra overhead. at the very least you should use a single 1d vec and do some arithmetic to index it properly. The only time i use a vec of vecs is when i actually need an array over arrays of many different sizes. yeah, technically the test cases as currently written call for this, but i don't think this should be. and though i haven't checked, your comment seems to imply not all languages take this approach. But more importantly, defining types concretely like this is less error prone. the size of a sudoku board doesn't change, and it's always square, so defining your type that way is a great help. if you want to handle missing values, then i would do it like this:

Sudoku<const N: usize>{
    data: [[Option<u32>; N]; N]
}

this actually makes sense, as a sudoku can't be oddly sized, but it can have missing numbers.

if this "loose typing" approach can be avoided, then it should be. but that's just my two cents.

edit: i was wrong, just checked and it seems all the language translations have oddly sized inputs. this is an odd choice to me, but it's at least consistent.

to see more of what I'm talking about, look up "parse, dont validate".

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.

rust should use a const generic and 2d array instead of a vec of vecs.
e.g.

Sudoku<const N: usize>{
    data: [[u32; N]; N]
}
impl<const N: usize> Sudoku<N> {
    fn is_valid(&self)-> bool{}
}

thanks

This kata is mostly broken and abandoned (see the high number of open issues). So, to answer your question: is that normal? Not really, ideally. But it probably won't be fixed for a while, there are more urgent problems.

Though, I don' think it rejects a correct answer, but I am not sure either. You should try to print the input by yourself (println!("{:?}",self.data); inside is_valid).

the Kata passes when I click test, but fails on clicking attempt.
the error messages doesn't show me which test cases fail, is that normal ?

trying it in rust

Python: the issue noted by @Matyt 7 years ago, that bool is a subclass of int and yet considered invalid, is still present.

The following are all True in Python:

False == 0
isinstance(False, int)
True in [1, 2, 3]

Requiring the validation to fail on boolean values breaks the usual assumptions on these things (e.g. that a subclass can be used wherever the parent class can). At the very least, the fact that bools are disallowed should be explicitly noted in the description.

Incorrect answer for board:

738|951|462

462|387|195

195|624|738

---+---+---

195|624|738

738|951|462

462|387|195

---+---+---

195|624|738

462|387|195

738|951|462

: True should equal False

Cases like this do not work without the row or column check

Update kata?

In a sense, yes. Consider that each cell of each row/column is part of some block (little square). A mistake in any cell (which you might consider a mistake of that row/column) is then automatically also a mistake in a block. Basically, any invalid cell makes the entire puzzle invalid.