Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TapEach For Futures and Try #44

Open
sinanspd opened this issue Nov 20, 2020 · 3 comments
Open

TapEach For Futures and Try #44

sinanspd opened this issue Nov 20, 2020 · 3 comments
Labels
enhancement New feature or request library:concurrent status:pending This enhancement request lacks consensus on whether or not to include it

Comments

@sinanspd
Copy link

sinanspd commented Nov 20, 2020

Reviving this old idea that we closed under scala/scala-dev#661.

Motivation

  1. Currently andThen defined for Futures, doesn't preserve the error behavior. We could argue that if the side-effecting code throws an error, the Future is ought to fail, as @NthPortal previously pointed out, preserving the behavior in Iterator and LazyList

  2. More consistent interface for all Monadic Product types (Option, List, all other Iterables etc.). If you want to do something like

Future|Option|Try .log(s"logging the value $_").map(...).log(...)

You either need to put F|O|T.map(r => { log(....) r}) every where, which is rather ugly,

Or you need to define extension methods on all them

implicit class MonadicLog[+B <: Product, A] (val u: B){
  def log(l: String): B = {
      log(l)
      u
    }  
 }

implicit class FutureLog[T, A](val u: Future[T]){
    def log(l: String) : Future[T] = {
      println(l)
      u
    }
  }

And so on ....

with a consistent tapEach operation, you can do the following, which is much better IMO

Future.successful(List(Some(1), Some(2), Some(3), Some(4)))
   .tapEach(println)
   .map(_.flatten
        .tapEach(println)
        .filter(_ > 1)
   ).tapEach(println)

I have a draft PR for this, I will push that for everyone to see what this would look like.

Open to comments :)

@SethTisue
Copy link
Member

previous PR was scala/scala#8857

@NthPortal NthPortal added enhancement New feature or request library:concurrent labels Nov 20, 2020
@NthPortal NthPortal added the status:pending This enhancement request lacks consensus on whether or not to include it label Nov 21, 2020
@NthPortal
Copy link
Contributor

everyone okay with this change? (👍 in favour, 👎 against)

@NthPortal
Copy link
Contributor

NthPortal commented Dec 3, 2020

I want to note that if we do this, we should clearly document the difference between this and andThen (perhaps even tweaking the stdlib scaladoc as well?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request library:concurrent status:pending This enhancement request lacks consensus on whether or not to include it
Projects
None yet
Development

No branches or pull requests

3 participants