Try to go back to pin based approach

[DasLixou]

Going back to a pin based approach allows us to directly use pointers (which for some cases could in theory be valid for longer than a single event like init or a button press, but this needs more consideration because it could lead to multiple exclusive references).

This could also get rid of the lens table overhead and be useful for futures, where the data they could be directly pinned into that composition.

For that to work smoothly, there are some thing needed:

• OwnedPin - a pin where the underlying data is wrapped in a ManualDrop and the real drop implementation is handled by the OwnedPin - see old ResponsiblePin for reference
  • For this to work safely and properly upholding Pin's conditions, this would require making OwnedPin !Forget, which is a concept currently only in RFC Proposal phase
  • For this to work nicely, it would be great to have general projection, which could be applied to Pin, MaybeUninit and similar. See the related RFC Proposal.
  • Also, keep an eye on the RFC Proposal for destructuring of types implementing Drop, which will help us move out the inner pin easier and more safely
• To address correct dropping on panics inside construction of the composition and other places where things other than a move are hard (e.g. inserting into a Vec), there should be a new Composition struct which, next to the old NonUninitComposition holds a bool, similar to an Option, which gives a clear value of whether the inner value is fully initialized or not.
  • If we can assure that Option doesn't optimize something away, we can also use that. Otherwise it could lead to problems where we have only partially initialized the value, e.g. the first NonZero value is already 42, so the enum thinks it's Some, but we're not fully initialized.
  • There could be made an optimization later where when a user has a custom enum for selecting between different compositions, making them add another None-like unit variant and skipping the init bool in the Composition struct, but that may also be directly done by the compiler itself..
  • On places where the composition is just initialized once and then persists, e.g. when adding a static child composable which will always be there - just like with the old ResponsiblePin design - we can directly use an owned OwnedPin and thus cast it from an OwnedPin<MaybeUninit<NonUninitComposition>> to an OwnedPin<NonUninitComposition> after initialization is done.

[DasLixou]

Actually, while those RFCs come in handy, I don't think they're needed.
Especially the forgot thing can be worked around quite easily with just a OwnedPin::new(|p| p) function which takes a closure taking a lifetime-branded OwnedPin and needs to get back an OwnedPin with that same brand.