tree 3f1b65eae0340ed539cacaaba905c4b5b5e47592
parent 3bd8b7c704daf5c9ff1b700625754b24b591ae32
author Devin Jeanpierre <jeanpierreda@google.com> 1653397234 -0700
committer Copybara-Service <copybara-worker@google.com> 1653397270 -0700

Support unions in `#[recursively_pinned]`, albeit without supporting pin-projection.

The rationale for why unions don't receive a `pin_project` function is documented here -- tl;dr we can't project because we can't know which field is active.

Users can just do it by hand, if they do know which field is active. Alternatively, we can add -- and this is still open even for structs -- we can add field-specific accessors, like `union U { x: i32, y: i64}` could have `project_x()` and `project_y()` functions.

The rationale for why we *should* support unions isn't documented, it's somewhat taken as a given, right? But like -- when this was originally written, I don't think I fully appreciated that this would be applied to literally every C++ type. And some features will apply to some types, and others to other types. For another example, I will be adding *pointer* projection in a followup CL, and that *will* support unions (but won't support enums!)  The only type that's going to have every single subfeature supported is likely going to be structs. :)

PiperOrigin-RevId: 450662659