Add Result.Extra.collect

[gampleman]

collect : List (Result e a) -> Result (List e) (List a)

Particularly useful for validation, it collects all the errors in the list, so they can all be shown at once to the user.

Motivating use case

Validation almost always needs this, but pretty much any library where we want to show good error messages needs to not loose information.

Rationale

This tends to be in practice more useful than Result.Extra.combine, as when using Result, we actually care about the error type.

collect : List (Result e a) -> Result (List e) (List a)
collect =
  List.foldr (\ra soFar -> 
    case (ra, soFar) of
       (Err x, Err y) ->
         Err (x :: y)

       (Ok _, Err _) ->
          soFar
       
       (Err x, Ok _) ->
          Err [ x ]

       (Ok x, Ok y) ->
          Ok (x :: r)

  ) (Ok [])

or some such. Not terrible to write, but not exactly a handy one-liner either.

Name

collect is just a spitball idea, moderate bike-shedding welcome.

[miniBill]

classify? I don't love it though

[miniBill]

Also, if you do this you should have it be List (Result e a) -> Result (e, List e) (List a)

[Andrew-Clow]

As someone who regularly uses a datatype

type Answer n y 
    = No (List n) 
    | Yes y

(precisely because it's better for validation than Result), I can agree with miniBill and confirm that allowing Err [] is a bug waiting to happen, and that when you combine multiple validation results, the existence of Err [] allows the code to conclude that everything's fine when it's not. The existence of No [] in my own code is exactly the reason that prevents me from publishing the Answer library.

I never find time to change the data type and update the library in all the projects that use it, but if I could go back in time, I would use non-empty lists. <- you are here.

[miniBill]

I wonder if just using ResultME is the correct plan here