Separate the iterator consumption from slice production

[kvark]

I wanted to write the following code:

        let mut src_stages = vk::PipelineStageFlags::empty();
        let mut dst_stages = vk::PipelineStageFlags::empty();
        let vk_barrier_iter = barriers.map(|bar| {
            let (src_stage, src_access) = conv::map_buffer_usage_to_barrier(bar.usage.start);
            src_stages |= src_stage;
            let (dst_stage, dst_access) = conv::map_buffer_usage_to_barrier(bar.usage.end);
            dst_stages |= dst_stage;

            vk::BufferMemoryBarrier::builder()
                .buffer(bar.buffer.raw)
                .size(vk::WHOLE_SIZE)
                .src_access_mask(src_access)
                .dst_access_mask(dst_access)
                .build()
        });

        inplace_or_alloc_from_iter(vk_barrier_iter, |vk_barriers| {
            if !vk_barriers.is_empty() {
                self.device.raw.cmd_pipeline_barrier(
                    self.active,
                    src_stages,
                    dst_stages,
                    vk::DependencyFlags::empty(),
                    &[],
                    vk_barriers,
                    &[],
                );
            }
        });

Rust doesn't like it, because both closures happen to access src_stages/dst_stages. But technically, we know that the second closure should be invoked on a slice, after the iterator is fully consumed. So I think there is a way here to expose this constraint via the API.
Perhaps, it would work nice if the API looked like this:

inplace_or_alloc_from_iter(vk_barrier_iter)
  .place(|vk_barriers| {..});

This way Rust compiler would see that the iterator is consumed separately from the slice processing, and would allow us to do this.

I'm currently thinking of the best ways to work around this, and it's not obvious, unfortunately.

[kvark]

Actually, worked around by just keeping temporary vectors around. I think I'm going to keep it this way for this kind of usage, so this issue is no longer pressing or blocking.

[NotIntMan]

This is nice idea. I will think about this style of API.
But this will be a breaking change so I won't finish this feature quickly.
Also, since this is no longer a problem, I am converting this issue into a discussion.