Adding get, getOrElse, toFuture to zio.prelude.Validation

[subotic]

I would like to suggest a few methods for zio.prelude.Validation:

• get
• getOrElse
• toFuture

If someone would be generous enough to provide some pointers and to hold my hand a bit, I would like to take a stab at implementing those myself.

[adamgfraser]

@subotic Yes that would be great!

I think I would prefer to avoid get as it would only be defined if E was a subtype of Throwable and would not be safe since it would throw exceptions.

getOrElse definitely makes sense and could have a signature like:

trait ZValidation[+W, +E, +A] {
  def getOrElse[A1 >: A](fallback: A1): A1 =
    ???
}

It could also make sense to have a variant that returned the log:

trait ZValidation[+W, +E, +A] {
  def getOrElseLog[A1 >: A](fallback: A1): (W, A1) =
    ???
}

toFuture also makes sense I think. Future normally eagerly computes its value so we would not consider it purely functional but since the value in the Validation is already a pure value I don't think there is any harm in embedding it into a Future. The signature could be:

trait ZValidation[+W, +E, +A] {
  def toFuture(implicit ev: E <:< Throwable): Future[A] =
    ???
}

[subotic]

@adamgfraser thanks for the pointers. Let's see how far I'll get.

[sideeffffect]

We could also use something like this

trait ZValidation[+W, +E, +A] {
  final def valueOr[A1 >: A](f: NonEmptyChunk[E] => A1): A1
    ???
}

Analogously to
https://typelevel.org/cats/api/cats/data/Validated.html#valueOr[B%3E:A](f:E=%3EB):B

[sideeffffect]

We should be careful about toFuture. Future can contain at most one Throwable, so we would be loosing information here. Would be an easy to make mistake which users could regret.

[adamgfraser]

Yes. I think we could have a variant that let the user provide a function to convert the errors to a Throwable and in the default version convert the others into suppressed exceptions.

[sideeffffect]

We were actually working on something like that, weren't we? 😄
#610
#603

[adamgfraser]

😃 Yes we were debating the merits of suppressed exceptions though I think we have gone more in that direction with the recent efforts to make ZIO traces more similar to Java stack traces.