Closed TheSeamau5 closed 9 years ago
Following these guidelines I am going to close this, but I agree that this function would be very valuable and probably should be built in.
I was about to make the same issue, but maybe we should consider consistency with Dict.update.
Alternative plan:
update: Int -> (Maybe a -> Maybe a) -> Array a -> Array a
Personally, I want both.
@jinjor, I think your update
signature needs a few more details as to how it should be implemented.
For Dict
, the (Maybe a -> Maybe a)
argument allows a user to assign a default value if Nothing
exists at the index.
For an Array
, how would that work if your index is out of bounds?
For example, what does the following produce?
things = Array.initialize 5 identity
--=> Array.fromList [ 0, 1, 2, 3, 4 ]
addOrDefault : Int -> Int -> Maybe Int -> Maybe Int
addOrDefault x default y =
case y of
Nothing -> Just default
Just yy -> Just x + yy
Array.update 25 (addOrDefault 5 0) things
--=> ????
The benefit of update : Int -> (a -> a) -> Array a -> Array a
is that it's simple, useful, and has practically one implementation. Given your signature has tradeoffs and concerns beyond "change value at this index", it may belong in a separate library.
@boxofrox Ah, that's fair. You are right.
The following function would be very valuable and it would be best if the implementation were native:
This function would be analogous to
Array.set
and would be strictly equivalent to the following implementation using bothArray.set
andArray.get
.(so, here's a good unit/property-based test for the update function).
The goal of having a native implementation is to avoid getting and setting in two distinct steps. This function would prove invaluable in the update step of the Elm Architecture
This would avoid the troublesome need of using functions like
indexedMap
to do this sort of work, and a native implementation could fuse the setting and the getting step of this operation in a way that isn't possible currently.