You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
writePixel on a MutableImage seems to be intended as an abstraction of the underlying color (Pixel) implementation, as well as the coordinate mapping from (x, y) to a single integer index.
In my opinion, it seems unintuitive that writePixel does not check whether the supplied x coordinate exceeds the image's width. This usually does not even cause an error, but simply (due to the way mutablePixelBaseIndex is implemented) writes the pixel in a later row. Supplying a too large y always causes an out-of-bounds error (as expected).
Obviously, checking the boundaries on every single writePixel call could have some serious performance implications, which is why I suggest to add a new function, such as writePixelChecked or safeWritePixel (analogous to unsafeWritePixel) which would check the x and y coordinates separately against the image dimensions and either throw an error, or more nicely return a Maybe () or Either String ().
A suggestion for an implementation:
safeWritePixel:: (PrimMonadm, Pixela) =>MutableImage (PrimStatem) a->Int->Int->a->m (EitherString())
safeWritePixel image@MutableImage{ mutableImageWidth = w, mutableImageHeight = h } x y px
| x >= w =return$Left"x exceeds the image's width"| y >= h =return$Left"y exceeds the image's height"|otherwise=Right<$> writePixel image x y px
writePixel
on aMutableImage
seems to be intended as an abstraction of the underlying color (Pixel) implementation, as well as the coordinate mapping from (x, y) to a single integer index.In my opinion, it seems unintuitive that
writePixel
does not check whether the suppliedx
coordinate exceeds the image's width. This usually does not even cause an error, but simply (due to the waymutablePixelBaseIndex
is implemented) writes the pixel in a later row. Supplying a too largey
always causes an out-of-bounds error (as expected).This snippet reproduces the "x overflow":
Obviously, checking the boundaries on every single
writePixel
call could have some serious performance implications, which is why I suggest to add a new function, such aswritePixelChecked
orsafeWritePixel
(analogous tounsafeWritePixel
) which would check thex
andy
coordinates separately against the image dimensions and either throw an error, or more nicely return aMaybe ()
orEither String ()
.A suggestion for an implementation:
Which could e.g. be used as follows:
The text was updated successfully, but these errors were encountered: