In the grand scheme of things, it would be more exciting if

1. any NdProducer could be collected
2. Zip can be an NdProducer of tuples by default.
3. One could with a method - .map(f) - create a different NdProducer from a Zip value itself.

but it's not certain that the required changes are worth it. Or if @jturner314 hasn't implemented something similar already :)

Now using MaybeUninit, because Vec::drop is what makes it unsound to toss uninit elements around. This is a lot closer to what @jturner314 said all along. 🙂

For non-Copy elements (more specifically, elements with drop, but we don't have a trait bound for that); there are hints of solutions for collect - I have an unbeautiful prototype for counting elements and dropping the right number of them on panic; but this doesn't transfer at all to the parallel case (in the parallel case, we have multiple different "write heads" into the array, and they all need to "roll back" if any thread panics), and that's a sign a better solution is needed of that problem. So it's not coming here.

I'm also saying that I think it's important to handle drop correctly - on panic, the elements that were created should drop. It would be easy to ignore the problem by just saying that there is no drop handling, but I would judge that's not robust.

That said, if MaybeUninit arrays are just exposed, they are very useful and the user can decide themselves if they want to skip handling drops on panic.