gmethvin commented on PR #2684:
URL: https://github.com/apache/pekko/pull/2684#issuecomment-3978723228

   I'm open to either approach. The naming consistency of reclaiming 
`futureSink` in 2.x is appealing. But I think it's worth being precise about 
the behavioral difference, since "lazy vs eager" is also about side effects.
   
   For value-producing sinks, the eager approach is arguably what the user 
wants anyway:
   
   ```scala
   // Sink.seq on an empty stream
   Source.empty[Int]
     .toMat(Sink.futureSink(Future.successful(Sink.seq[Int])))(Keep.right)
     .run().flatten
   // Lazy: Future fails with NeverMaterializedException
   // Eager: Future succeeds with Seq.empty
   
   // Sink.fold on an empty stream
   Source.empty[Int]
     .toMat(Sink.futureSink(Future.successful(Sink.fold(0)(_ + _))))(Keep.right)
     .run().flatten
   // Lazy: NeverMaterializedException
   // Eager: Future.successful(0)
   ```
   
   I would expect that these users are already handling the 
`NeverMaterializedException` and mapping to an empty value, in which case that 
just becomes dead code, but it's not a breaking change.
   
   But for side-effecting sinks, eager evaluation changes observable behavior:
   
   ```scala
   // FileIO sink on an empty stream
   Source.empty[ByteString]
     .toMat(Sink.futureSink(Future.successful(FileIO.toPath(path))))(Keep.right)
     .run().flatten
   // Lazy: no file touched, NeverMaterializedException
   // Eager: empty file created on disk, IOResult(0, Success(Done))
   ```
   
   Anyone using `futureSink` with side-effecting sinks on potentially empty 
streams today might rely (intentionally or not) on the fact that the inner sink 
is never materialized. With eager semantics, those side effects would now fire.
   
   The question is how likely it is that someone is depending on this 
difference and also ignores both the 1.x deprecation warning and the 2.x 
migration guide. My guess is this is rare but not zero.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to