#[callback_vec] does not respect other callback parameters

[itegulov]

Consider following function:

pub fn foo(
    &self,
    #[callback_unwrap] a: u32,
    #[callback_unwrap] b: u32,
    #[callback_vec] other: Vec<u32>
) { ... }

Intuitively it feels like #[callback_vec] parameter should act as a trailing variadic for all remaining promise callbacks. So one would expect that if you pass 4 promises to foo, then a will resolve to the first callback, b to the second and other to the remaining two. The current implementation of #[callback_vec] behaves differently though: other will resolve to all four callbacks disregarding that a and b have already resolved the first two.

I can see two paths forward:

1. We forbid mixing #[callback_unwrap]/#[callback_result] and #[callback_vec] together since this can be a footgun. This would be a fairly small breaking change for people who were mixing this pattern for some reason. They could just remove the regular callbacks and grab them from the vector manually.
2. We change the semantics for #[callback_vec] to only unwrap promises that have not already been handled by other callback parameters. Also, forbid declaring #[callback_unwrap]/#[callback_result] parameters after the callback vec parameter (ensuring it is always the last one just to highlight this new semantics).

[itegulov]

Another idea is to combine this with #861 and create two new annotations #[callback_vec_unwrap] and #[callback_vec_result] with different semantics as described in item 2. This way the transition will be smoother.

[austinabell]

Also, if we change the semantics, we need to consider what happens when callback vec is before a specific callback. Does it pull all elements from promises len -2? What happens if callback_vec is in the middle? If there are two callback_vec, should we error at compile time?

[itegulov]

Also, if we change the semantics, we need to consider what happens when callback vec is before a specific callback. Does it pull all elements from promises len -2? What happens if callback_vec is in the middle?

Yeah that is why I said that we should probably enforce for callback vec to always be the last callback parameter.

If there are two callback_vec, should we error at compile time?

Probably, I don't see how two callback vec parameters could be useful