Should we provide our own join and select, or leave it to users?

[ColinWttt]

Since PR #1043, we now have an async runtime. I tried using futures::join! and futures::select!, and both worked well. I also tried futures-lite zip and or — lightweight alternatives to join and select that support only two futures. (itest: futures and futures-lite )

join and select seem highly useful in game development, yet Godot lacks similar built-in functionality.

For example, wait for multiple tween animations to complete. Alternatively, stop waiting if the user doesn’t press a key within 5 seconds.

Will gdext consider implementing them in the future, or should this be left to users, similar to how rand is handled?

[TitanNano]

All of these can easily be pulled in via futures-util, so I don't really see a point in reimplementing them. We could consider re-exporting future-utils from godot but I don't actually see an advantage in that.

[Bromeon]

It might still be worth documenting that futures-util can be used for join and select, what do you guys think?
We could then link to that crate from our API docs.

What would be a good place? Maybe TaskHandle?

[TitanNano]

Maybe in the module description of godot::task?

[Bromeon]

Also possible. Over time, we could then expand that with some examples.

The standard library typically does this too:

• https://doc.rust-lang.org/std/option
• https://doc.rust-lang.org/std/thread
• https://doc.rust-lang.org/std/primitive.slice