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".

totally fair, I can accept that invalidating current solutions is a no go.

reguarding bad assert messages and random board sizes, the assert macros are the same as the current version, and random board sizes are also not used. In fact, when generating random solutions, the current version only creates sizes of 4x4 and 9x9, despite comments claiming to create 3x3 (which is an invalid size), 9x9, and 16x16.
would you like me to submit a different fork that keeps the solution the same and addresses these already existing problems?

reguarding a vec of vecs being "completely fine", I personally disagree. the type system should be leveraged as much as possible to make invalid states unrepresentable. if you want me to handle garbage input, then give me a string to parse. yeah it works, but it is more like the way things are done in dynamically typed languages. On balance, however, i get that breaking current solutions is a problem.

This is a more idomatic way to handle 2d arrays of data.
a vec of vecs is generally a bad representaton, and with the stabilization of const generics in rust this better method can be used.

there is a downside, however: current solutions won't work anymore.

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{}
}