JEP 473: Proposal for new built-in gatherer `indexed`

[Olexandr Rotan]

Hi. There has been a proposal from me (that Chen mentioned), approximately
half a year ago. At the time I have insisted on creating stream sub
interface, and even got a working prototype for sequential streams, but
there have been such a huge complexity blowup in parallisation that I have
just decided to drop it. Gatherers can be used pretty easily for this task,
but using ofSequential, sacrificing parallelism. So basically, parallelism
is a pain point here (or performance). I am not saying that it is
impossible to console enumeration and prallelisation, but it will require
huge efforts and invasive changes in current *Pipeline implementations, or
enormous amounts of code duplication

On Thu, Dec 5, 2024, 18:48 Henrik Wall <xehpuk.dev at gmail.com> wrote:

> Hey folks,
>
> Not having access to the index of an element of a stream is often a
> reason to fall back to a traditional loop, at least for me. I'd love
> to have `Gatherers.indexed()` that looks something like this:
>
> public static <TR> Gatherer<TR, ?, Map.Entry<Integer, TR>> indexed() {
>     return Gatherer.ofSequential(
>             () -> new int[1],
>             Gatherer.Integrator.ofGreedy((state, element, downstream) ->
>                     downstream.push(Map.entry(state[0]++, element)))
>     );
> }
>
> (Potentially with a custom pair class to avoid auto-boxing.)
>
> In other popular languages like Python or Rust, this is also called
> `enumerate`.
>
> Any chance to get that in a future release?
>
> Regards,
> Henrik
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241205/fdfcfae1/attachment.htm>