For parallel iteration. Probably gotta think about Send/Sync as well.

Stuff like Debug, Copy, Clone, etc.

Choose some sensible settings and put the dot-file in repo. Make a note to add it to CI when that is done.

Write benchmark similar to tests/blur.rs. Should compare crates block-grid, toodee, and array2d. For each, test against a common naive indexed version (Index<Coords>) and an idiomatic version.

Rust 1.51 will have min_const_generics which eliminates the need for BlockWidth generics. However, the current method will still work, so I'll probably delay it for a bit while people trickle over to the latest version. Obviously gonna be a breaking change.

Add a bunch of useful stuff to the README.

Similar to #1, create a benchmark that runs Conway's game of life. Should benchmark the following versions.

• Generic indexed approach (Index<Coords>)
• Idiomatic BlockGrid
• Idiomatic array2d
• Idiomatic toodee (#19)

Create methods raw() and raw_mut() on Block/BlockMut to get a reference to the internal slice &[T]. This might be needed for some block-level algorithms.

There's no reason a user would need to implement CoordsIterator, and also current_coords() shouldn't need to be called by users, so see if it is possible to make the trait "pseudo-private", so they can access it, but can't implement it, and also coords() is the only public method available.

See Clippy lint. Change unit error in Result<Self, ()> to something proper. See following for example. Best fix is probably a singleton enum InvalidSize cause that's the only failure mode. Discovered in this lint run.

Change the iteration item for each_iter to (Coords, &T) (similarly with each_iter_mut). I wanna do this so that if you just wanna iterate over each element, but still need the indices for some reason. Using row_major_iter for that will be slower b/c of block changes every few elements. Basically, if you need to iterate over each element (with coordinates for whatever reason), it should be done in storage order. Also, as with row_major and block_iter, you can't just user .enumerate() to calc. 2D coordinates on the fly.

Just from thinking about it, this seems kinda annoying, b/c generating the coordinates from the in-memory index is weird. I think it would be useful though.

Could be done by supporting a block width of U1. Just need to check if it all works out.

A few reasons why this might be useful:

• Allow testing to see if blocks is useful at all (try U1 vs other block widths and see performance)
• If both needed, don't need a whole other library
• Even if only U1 needed, I think this lib has a decent interface and some useful helper funcs that still apply

It's pretty annoying to have to use BlockWidth::*, so just put the U_ values in the crate namespace.

Create a BlockGrid::raw and raw_mut returning a references to the buf field. Also, you can't grow mutable array references right..? That wouldn't make much sense.

BlockGrid::from_row_major and from_col_major share most of their code. Either use a macro or a helper method to combine em. The only different part is the index calculation.

Should create a in-memory/each/row-major (all the same) iterator for Block and BlockMut. I think this could be useful when using block_iter.

Don't know if this was be particularly useful, but consider allowing non-square block sizes. This is two ways of implementing it.

Could by done by parameterizing as BlockGrid<W: BlockDim, H: BlockDim, T> where W and H are block width and height respectively. A SquareGrid type-alias could be for square blocks.

Alternatively, a BlockDims trait which itself holds the block and width. Would then have to create a buunch of types for each combination, such as U4ByU8 (or U4xU8), with type-aliases for the current square blocks.

Follow up of #1. Write tests and benches for:

• Idiomatic block-grid (#21)
• Idiomatic array2d (#20)
• Naive indexed with toodee (#16, #19)
• Idiomatic toodee (#17)

There are a bunch of small methods which I can mark as #[inline] to further optimize across crate boundaries. Build times with LTO are annoying, so this should close the gap a little. Should also hopefully give better benchmarks results.

Serialization support. Probably would be easy to add cause there's nothing fancy to store. Just gotta figure out the no_std and crate options/features stuff.

Find all the places where I can "safely" use unchecked operations to increase performance. Investigate the performance gain (if any), and change if worthwhile. Remember to add debug assertions for a bit of safety.

Little helper function that rounds up rows and cols to next multiple of B::WIDTH.

Make crate no_std compatible. Because Vec is used to store data, alloc is used for collections.

Consider making this crate no_std compatible. The data is stored in a Vec however, so alloc will be needed.

#24 introduced coordinates to each_iter, but the implementation is done via a on-the-fly calculation from an enumerated index. Should implement a EachIterCoords iterator with an inner iterator, that tracks the coordinates during iteration. This might improve performance instead of calculating from scratch every time.

Bug in the impl of Iterator::nth for WithCoordsIter . When n = 1, the if isn't triggered, and the returned value is wrong. The condition needs to be if n >= 1.

Look into having a BlockGrid with dimensions that are not a multiple of B::WIDTH. There would then be two pairs of dimensions, an actual and an internal. It don't think it affects indexing into a BlockGrid too much, cause you just replace the bounds check to use the actual dimensions. Adjusting EachIter might be annoying. Handling incomplete Blocks on the border is gonna be ugh 😿.

Rework the innards of Block and BlockMut to be faster. Will probably involve some unsafe stuff.

Write some basic crate, type, and method documentation.

I'm not quite sure what needs to be done, but set up stuff for library and method documentation.

Follow up of #9. Make the manually triggered pipeline checkout the base branch (probably just master), save a baseline, and then bench again with the actual branch. Criterion should then give you the perf delta.

Also look into using the critcmp tool to see if it has any nice features.

Block{Mut}::new is pub(crate), but since it only debug asserts, it can lead to unsafety if incorrect sized slice passed in.

Consider Github Actions vs Travis.

Relates to #2.

Consider changing buf: Vec<T> to a Box<[T]> cause it has a static length, which aligns with BlockGrid use of the memory.