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.concan...@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
