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
Currently findFailFn isn't particularly helpful, essentially just being a serialized version of map _ xs | findFail (which itself might actually be desirable in certain niche circumstances) and those semantics don't match its name pattern as a variant of findFail. I'd like to propose we change its signature from (a => Result b c) => List a => Result (List b) c into (a => Result b c) => List a => Result (List a) c -- note the final List.
Effectively, that means it wouldn't perform the unwrapping of each list element that findFail does, but instead allows for nondestructive checking by returning the original list ("for every String in the list, ensure it's a key in this map without replacing the String with the associated value"1), or for validating complex types along the lines of Pair a (Result b c) but where the Resultcan't be easily promoted out, or in cases where some evaluation needs to be done to ensure the value's valid but where the result of that evaluation isn't important.
This would obviously be a breaking change and require concerted migration of old code before we could roll it out, but that's a hole which we currently would have to awkwardly code around if it were to ever come up, and would give findFailFn a distinct purpose rather than its current limbo.
Footnotes
Ignore the fact that that can currently be done with findFailFn (\str if mcontains str registry then Pass str else failWithError "...") and imagine that it's easier to write findFailFn (mlookup _ registry | getOrFail "...".makeError); I just don't have a better example offhand. ↩
The text was updated successfully, but these errors were encountered:
Currently
findFailFn
isn't particularly helpful, essentially just being a serialized version ofmap _ xs | findFail
(which itself might actually be desirable in certain niche circumstances) and those semantics don't match its name pattern as a variant offindFail
. I'd like to propose we change its signature from(a => Result b c) => List a => Result (List b) c
into(a => Result b c) => List a => Result (List a) c
-- note the final List.Effectively, that means it wouldn't perform the unwrapping of each list element that
findFail
does, but instead allows for nondestructive checking by returning the original list ("for every String in the list, ensure it's a key in this map without replacing the String with the associated value"1), or for validating complex types along the lines ofPair a (Result b c)
but where theResult
can't be easily promoted out, or in cases where some evaluation needs to be done to ensure the value's valid but where the result of that evaluation isn't important.This would obviously be a breaking change and require concerted migration of old code before we could roll it out, but that's a hole which we currently would have to awkwardly code around if it were to ever come up, and would give
findFailFn
a distinct purpose rather than its current limbo.Footnotes
Ignore the fact that that can currently be done with
findFailFn (\str if mcontains str registry then Pass str else failWithError "...")
and imagine that it's easier to writefindFailFn (mlookup _ registry | getOrFail "...".makeError)
; I just don't have a better example offhand. ↩The text was updated successfully, but these errors were encountered: