zio-prelude v1.0.0 - Roadmap

[guizmaii]

@sideeffffect @kyri-petrou @jdegoes @ghostdogpr, please add anything you think we should fix/improve/change before releasing v1.0.0. Feel free to disagree with my points, of course 🙂

List of things to fix/improve/change before to release v1.0.0:

1. • Inconsistent usage of the fish operators (aka <* & *>).
     In ZIO, zio(v0) *> zio(v1) means zio(v0).flatMap(_ => zio(v1)) and zio(v0) <* zio(v1) means zio(v0).flatMap(vv0 => zio(v1).as(vv0))
     In zio-prelude, the AssociativeBothCovariantOps add these operators as aliases for zipLeft and zipRight
2. • ZValidation.zipPar (and all the associated variants) are not parallelizing anything. They need to be renamed .zip.
3. • Inconsistent usage of the "par fish" operators (aka <& & &>).
     in ZIO, a &> b mean that a and b will be forked.
     In zio-prelude ZValidation, they are not forking anything and just aliases for .zip (Related to point 2 of this ticket)
     Do we have the same issue anywhere else in zio-prelude? 🤔

[sideeffffect]

Looks good to me! Thanks for the initiative.
I'd like to get this merged (and have the linked PRs closed as deprecated):

• Enable converting ZValidation.Failure to an exception #1360

[kyri-petrou]

There is only one thing that comes to mind but I'm not sure whether it's even possible without a very major refactoring.

The ForEach type-class is defined as:

trait ForEach[F[+_]] extends Covariant[F]

This means that we can't provide ForEach instances for invariant types. A usecase where this is problematic, I wanted to use zio-prelude with doobie's Connection (which is Invariant) and wasn't able to because the compiler doesn't allow it.

[jivanic-demystdata]

@jdegoes Any thoughts about @kyri-petrou's Covariant issue?

[kyri-petrou]

PS: I don't think we should try to address this for the v1 release. I just thought to point it out in case someone might have a simple solution in mind that wouldn't require a huge rewrite of the typeclass hierarchies