Transfer api bug: `nonEmptyIterator` doesn't handle views that become empty during iteration
MattiDragon opened this issue ยท 0 comments
This was first reported in MattiDragon/ExtendedDrawers#81 where the compacting drawer storage returned an empty view in nonEmptyIterator
due to it becoming empty after the iterator checked it's state. The root cause is that the iterator implementation stores the next view, if available, on call to next
. In cases such as the compacting drawer, a view can change before it has be returned from the iterator due to other views affecting it's state. I've implemented a fix in this commit, but it would be nice if the default implementation handled this edge case.