Provide map() and map_mut() for par_iter_mut()

[mscofield0]

What problem does this solve or what need does it fill?

For when you need to iterate through a query and generate some sort of result from each of the parallel iterators. e.g. reading websockets of sessions and then returning the locally collected requests, flattening it and collecting them all into a single requests list for further processing.

What solution would you like?

I would like map() and map_mut() (because websocket readers require mutable access). They should be used like so:

fn read_ws(mut query: Query<(&mut WsReader)>) {
  let reqs = query
    .par_iter_mut()
    .map_mut(|(mut ws_reader)| {
      let mut reqs = Vec::new();
      // ... reading from the ws reader
      reqs
    })
    .flatten()
    .collect::<Vec<_>>();
}

What alternative(s) have you considered?

The alternative is cumbersome, but doable:

let len = query.iter().len();
let mut i = AtomicUsize::new(0);
let mut reqs = Arc::<Vec<MaybeUninit<Vec<wire::Req>>>>::default();
reqs.resize_with(len, || MaybeUninit::uninit());
query.par_iter_mut().for_each_mut(|(mut ws_reader)| {
  let local_i = i.fetch_add(1, std::sync::atomic::Ordering::AcqRel);
  let mut local_reqs = Vec::new();
  // ... read from ws
  reqs[local_i] = MaybeUninit::new(local_reqs);
});

let reqs = unsafe { std::mem::transmute::<_, Vec<Vec<Req>>>(results) };
// do something with reqs

As you can see, not very pretty.

[alice-i-cecile]

Fully on board with this. Do we want filter and reduce as well?

[mscofield0]

Might as well!

[hymm]

note that for this specific use case it's probably better to do what bevy is doing internally and use the thread_local crate and store the thread local inside of a Local<T>, so that you can reuse the allocations.

bevy/crates/bevy_render/src/view/visibility/mod.rs

Lines 385 to 386 in 6f2a5cb

	pub fn check_visibility(
	mut thread_queues: Local<ThreadLocal<Cell<Vec<Entity>>>>,

We have this PR to make that pattern more ergonomic #7348.

For more parallel iterator methods, we have a bunch of traits in bevy_tasks that used to be implemented on queries, but were not ported over with the ecs v2 rewrite. I'm not sure if we should use those or just throw them away and write something else.