Feature: Provide getters of data and vtable pointer for `RawWaker`?

[oxalica]

Docs of std::task::RawWaker:

It consists of a data pointer and a virtual function pointer table (vtable) that customizes the behavior of the RawWaker.

We said it consists of two pointer, but doesn't enforce its layout by repr, nor provide methods to get data and vtable pointer from a constructed RawWaker. So it impossible to destruct a RawWaker even with transmute, since the layout is unknown, which makdes it difficult to pass RawWaker or Waker across FFI boundary.

Note that Waker has repr(transparent) on it so it's able to transmute into a RawWaker. But it barely does anything since we can do nothing with a RawWaker. I'm confusing about why there is a repr(transparent) struct to an blackbox struct without any methods.

If it's intended to NOT stabilizing the layout of std::task::RawWaker. I think we should at least provide methods like fn data(&self) -> *mut () and fn vtable(&self) -> &'static RawWakerVTable to do the inverse of RawWaker::new, which can be used to destruct it to cross FFI boundary.

[yoshuawuyts]

We discussed this during today's triage meeting, and the async foundations WG is generally +1 on this idea.

cc/ @rust-lang/libs what do you think the right steps here should be?

[cuviper]

It makes sense to me, but it's more precisely a question for @rust-lang/libs-api.

[tmandry]

wg-async-foundations discussed and we're generally supportive of the idea, but agreed it's the libs API team who owns this.

[joshtriplett]

We discussed this in today's @rust-lang/libs-api meeting. We're in favor of adding these methods, as inverses of RawWaker::new. Please feel free to send a PR adding these as unstable APIs and we'll r+ it.

[eholk]

@rustbot label +AsyncAwait-Triaged