only checks the overlap between corresponding elements, but if you used something like
roll (MV_3 n as bs cs) = MV_3 n bs cs as
then something like overlaps mv (roll mv) will report False even though it has arrays that 'overlap' the originals rendering destructive changes hazardous.
I'm not really sure that this is such a damning failing, none of the existing combinators will produce such a rotation, but I figured it was worth capturing in an issue rather than passively ignoring the concern.
An example of where it might matter would be if you let zip for unboxed vectors try to get clever about reusing the source vectors.
The current
basicOverlaps
check doesn't actually fully determine if each of the constituent sub-arrays overlap.e.g.
only checks the overlap between corresponding elements, but if you used something like
then something like
overlaps mv (roll mv)
will reportFalse
even though it has arrays that 'overlap' the originals rendering destructive changes hazardous.I'm not really sure that this is such a damning failing, none of the existing combinators will produce such a rotation, but I figured it was worth capturing in an issue rather than passively ignoring the concern.
An example of where it might matter would be if you let zip for unboxed vectors try to get clever about reusing the source vectors.