Re: RFR[8238286]: 'Add new flatMap stream operation that is more amenable to pushing’

[Paul Sandoz]

Hi Patrick,

This looks good. To resolve the ambiguity of when results are undefined I suggest we tweak the docs at the various locations, see below. No need for another round of review.

I can understand the desire to place the primitive functional interfaces in j.u.functions, but for reasons previously stated they are fine in the current location.

Paul.



      * accepts replacing elements. The mapping function operates on the consumer,
      * zero or more times, for acceptance of replacing elements.
      *
-     * <p>The results of this method are undefined if the {@link Consumer}
-     * argument is called outside the scope of the mapper function.
-     *
      * <p>This is an <a href="package-summary.html#StreamOps">intermediate
      * operation</a>.
+     * The results of this intermediate operation are undefined if the
+     * {@code consumer} argument is operated on outside the scope of
+     * its application to the mapping function.
      *
      * @implSpec
      * The default implementation accumulates accepted elements into an internal

> On Aug 11, 2020, at 11:11 AM, Patrick Concannon <patrick.concannon at oracle.com> wrote:
> 
> Hi,
> 
> Please find the next iteration of mapMulti in the new webrev below. 
> 
> In this iteration the following changes have been made:
> The API note for mapMulti has been updated.
> Sub-interfaces for {Int, Double, Long}Stream have been refactored to be more specific to mapMulti.
> The examples have been changed, and now include a reference to how an explicit type parameter can be used in conjunction with mapMulti.
> 
> The CSR and specdiff have also been updated to reflect these changes.
> 
> webrev: http://cr.openjdk.java.net/~pconcannon/8238286/webrevs/webrev.05/
> specdiff: http://cr.openjdk.java.net/~pconcannon/8238286/specdiff/specout.02/
> CSR: https://bugs.openjdk.java.net/browse/JDK-8248166
> 
> Kind regards,
> Patrick