In-place initialization

[nikomatsakis]

Metadata
Point of contact	@Darksonn
Team(s)	lang
Goal document	2025h2/in-place-initialization

Summary

Evaluate approaches for in-place initialization and pick one.

Tasks and status

• Discussion and moral support (lang )
• Design meeting (lang )
• Be the main author of an RFC (@Darksonn)
• Contribute to the RFC (@cramertj, @yoshuawuyts, @BennoLossin, @nbdd0121)
• Lang-team liason (@joshtriplett)
• Dedicated reviewer (@compiler-errors)

[nikomatsakis]

This issue is intended for status updates only.

For general questions or comments, please contact the owner(s) directly.

[Darksonn]

This is our first update we’re posting for the in-place init work. Overall things are progressing well, with lively discussion happening on the newly minted t-lang/in-place-init Zulip channel. Here are the highlights since the lang team design meeting at the end of July:

• Zulip: we now have a dedicated zulip channel that includes all topics surrounding in-place initialization: #t-lang/in-place-init.
• Guaranteed value emplacement: Olivier FAURE shared a new version of C++ inspired emplacement in #t-lang/in-place-init > RFC Draft: Guaranteed Value Emplacement inspired by C++’s emplacement system.
• Rosetta code sample: to help guide the comparison of the various proposals, we’ve started collecting examples to compare against each other. The first one was contributed by @Darksonn and is: “How can we construct a Box<Mutex<MyType>> in-place inside the Box”. For more see #t-lang/in-place-init > Shared example: emplacing into `Box.
• Evolution of the outptr proposal: @cramertj’s original outptr-based emplacement proposal used concrete types as part of her proposal. Since then there has been significant discussion about alternative ways to represent out-pointers, including: #t-lang/in-place-init > out-pointer type and MIR semantics consideration.
• Placing functions as a high-level notation: @yoshuawuyts has begun reworking the “placing functions” proposal as a high-level sugar on top of one of the other proposals, instead of directly desugaring to MaybeUninit. For more see: #t-lang/in-place-init > Placing functions as sugar for low-level emplacement.
• Generic fallibility for the Init proposal: following feedback from the lang team meeting, @Darksonn posted an update showing how the Init trait could be made generic over all Try types instead of being limited to just Result. For more see: #t-lang/in-place-init > Making impl Init generic over Result/Option/infallible.
• Interactions between emplacement and effects: @yoshuawuyts has begun documenting the expected interactions between placing functions and other function-transforming effects (e.g. async, try, gen). For more see: #t-lang/in-place-init > placing functions and interactions with effects.

[Darksonn]

On Nov 12th, there was a mini-design meeting organized by Xiangfei Ding on inplace initialization. The attendees were Xiangfei Ding, Alice Ryhl, Benno Lossin, Tyler Mandry, and Taylor Cramer.

We discussed this document: https://hackmd.io/@rust-for-linux-/H11r2RXpgl