Zio: Enrich Iterable with ZIO combinators

[evis]

e.g., put this into ZIO companion object:

implicit class RichZIOIterable(private val as: Iterable[A]) extends AnyVal {

  def foreach_[R, E, A](f: A => ZIO[R, E, Any]): ZIO[R, E, Unit] =
    ZIO.foreach_(as)(f)
}

Same for all other combinators which work on Iterables.

It would allow for more convenient and readable syntax:

elements.foreach_(handle)

compared to

ZIO.foreach_(elements)(handle)

[adamgfraser]

Personally I'm not a big fan of this. Generally we have tried to avoid implicit syntax where possible because it makes methods less discoverable, can require imports, and can not always be available. We just recently removed implicit syntax similar to this in #2361.

In this case in particular many combinators we would like to use are already defined for collections. Your example works for foreach_ but I don't think it would work for foreach because of the existing method defined with that name, which creates another issue where some combinators are available with this syntax and others are not for a relatively arbitrary reason. Also if you have any other implicit syntax from somewhere else that is providing "collection" methods from somewhere else you could have conflicts.

I agree that the infix syntax is nice but the companion object syntax is also relatively terse and readable so I don't think this is necessary.

[evis]

Users of ZIO companion object methods don't lose anything. They just continue to use them and don't care about discoverability issues and imports.

As cats/cats-effect user, I (and my team) just used to infix methods like sequence, traverse, etc. So, users who prefer infix methods will get better experience with such enriching. And for those, who don't care about infix syntax, just nothing changes.

Also, migration from cats-effect could be simplified a little bit with infix methods.

Maybe, companion object isn't really suitable for them, and it's better to use something like import zio.syntax.iterable._.

[jdegoes]

@evis Thanks for the great suggestion!

I think we should have a separate project for this, ZIO Stdlib / ZIO Syntax or something, which can have quite a few enrichments in it for classes in the standard library.

Because the problem with enrichments in core is determining when to stop: in ZIO core we could only include a couple (which ones???). But in a separate project we could really have a full suite of enrichments.

Let me know if you'd be interested putting something like this together!