There’s some inconsistency among the return types of these functions. Some return a Maybe while others don’t.
-- returns Maybe
-- Data.Array
updateAt :: forall a. Int -> a -> Array a -> Maybe (Array a)
-- Data.List
updateAt :: forall a. Int -> a -> List a -> Maybe (List a)
-- returns original
-- Data.Array
updateAtIndices :: forall t a. Foldable t => t (Tuple Int a) -> Array a -> Array a
-- Data.List.Lazy
updateAt :: forall a. Int -> a -> List a -> List a
Should we make these more consistent, even if that involves a breaking API change and a tedious update of many packages?
Originally asked about this here, where a wider discussion was suggested.
I previously have argued in favour of Maybe-returning functions to capture whether functions had an effect on the array, but I’ve changed my mind on that. In practice I’ve never made use of it, and end up doing the fromMaybe xs $ updateAt ... xs kinda thing that was mentioned. Same goes for insertAt, deleteAt, etc.
Admittedly, it’s very rare for me to write code that does things at specific indices in lists and arrays, so it’d be interesting to see what others think if they run into that situation more often.
I think breaking the API for better consistency between List and Array is a perfectly good excuse to do it too, I find it very annoying when there are differences between the two when switching types, and it’s bad for newcomer experience also. It’s not a bad time to discuss it either, given we’ll be wanting to do a batch of breaking changes after the next compiler release.
I agree on everything @garyb has said here; while I am generally against breaking changes, this seems like a glaring inconsistency which probably does justify them. I would particularly like to hear from others who are more skeptical though: if people think this change will be more painful than it’s worth, or if they are finding the Maybe versions useful.
I agree on everything