I was going through the coroutine_handle implementation from https://github.com/gcc-mirror/gcc/blob/master/libstdc++-v3/include/std/coroutine#L251 and I stumbled across the fact that coroutine_handle have void* member variable to store the address.
Since we can convert from address to any promise type and vice versa using coroutine_handle API, doesn't it imply that type system is being abused here?
Was it not possible to implement the coroutine_handle using type safe methods?
Edit: Just to give some context.. I was writing an event loop and was passing task object around different threads, with task class being a template type. I introduced a bug (unintentionally) and I was basically able to convert one task type to another, which had different memory layout (due to specialization).
As per cppcon videos I saw on YouTube (which I am following for almost a year by now), the committee is trying to fill the holes of type system in C++ (I guess the title of video was 'type punning in C++'). I didn't expect that I will be able to do type punning using the feature of C++ that was introduced in C++20.
First, the standard library cannot invoke undefined behavior any more than the compiler can invoke undefined behavior. They form the implementation of the language together. A user of the standard library may invoke undefined behavior by violating the rules of the implementation.
void* is a form of type erasure. It is often helpful to pass objects through layers of code or store them in containers, without everything becoming a template. The standard library has a few type-erased types, including
Type erasure is not type punning. When the library provides the ability to restore the type, the user must supply the correct type. One is not allowed to read a type as another type.
The main difference is
std::coroutine_handle::from_address enforces that with a precondition (and UB on violation) while
std::any_cast checks the condition. While UB is falling out of favor, preconditions and UB continue to appear in new non-trivial C++ types and that is unlikely to change.