Design meeting: In-place Initialization

[tomassedovic]

Summary

@Darksonn wrote a proposal about In-place initialization that would help the Rust for Linux effort:

https://hackmd.io/@aliceryhl/BJutRcPblx

cc @Darksonn @y86-dev @joshtriplett

About this issue

This issue corresponds to a lang-team design meeting proposal. It corresponds to a possible topic of discussion that may be scheduled for deeper discussion during one of our design meetings.

[tomassedovic]

We will schedule this for 2025-07-30.

[kennytm]

Isn't this something rust-lang/rfcs#2884 also trying to solve? I don't see any mention of it in the prior art (neither is the now-deleted "placement in" protocol). In terms of RFC 2884 a closure would take the role of this pre-RFC's "initializer", which the underlying semantic is to yield the layout, accepts an uninitialized memory, and return it initialized, without introducing any new syntax.

// this pre-RFC
let b = Box::init(init {
    let value = expensive_logic();
    [value; 1000]
});

// rfc 2884
let b = Box::with(|| {
    let value = expensive_logic();
    [value; 1000]
});

[y86-dev]

@kennytm Yes and no. The implementation is very different and it is solving additional problems that the given RFC doesn't address or can't solve.

I agree that we should mention it in the prior art. @Darksonn feel free to add this (or parts of it) to the prior art discussing the mentioned RFC. (or we do that when authoring an actual RFC)

When I initially wrote pin-init (Alice's proposal essentially turns that library into a language feature) for the kernel back in 2022, I looked through the various proposals on the issue of placement new and concluded 4 issues that were essential for the kernel (and not all were solved):

1. pin-initializing a slot
   This one is required for self-referential types that would like to be initialized in a state that already is self-referential. For example intrusive, circular, doubly linked lists (in the kernel these are used in mutexes and thus transitively embedded in a lot of types).

   I haven't seen this being solved anywhere except @nbdd0121's original attempt at pin-init and my pinned-init (that eventually became the kernel's pin-init).

2. generating a compile error if the value would not be in-place initialized
   in the kernel stack space is limited. Potentially storing a large type on the stack is a no-go and thus we want explicit syntax for the case where we want to ensure that the value is indeed initialized in-place.

   IIUC the RFC you cited does try to guarantee the optimization, but "guarantee" is not enough. We need a compile error if it couldn't be initialized in-place. pin-init achieves this through the use of explicit initializer types.

3. fallible initializers
   Initialization of certain types in the kernel can fail. And those types also sometimes need to be pin-initialized. Thus we need errors built into the initializers.

   The RFC acknowledges that functions returning Result<Struct, Error> do not work with GCE. However, the kernel really really needs fallible initializers.

4. composing initializers
   As mentioned above, mutexes are used a lot in the kernel. But how do we go about creating a constructor for a type containing a mutex? With pin-init, you just create a function fn new() -> impl PinInit<Self> that returns an initializer. Since they compose, one can easily create a mutex initializer and then use that to create an impl PinInit<Self>.

   The RFC only ever shows constructions of base types and importantly this example doesn't work:

   fn bad() -> Struct2 {
       let q = Struct { ... }
       Struct2 { member: q }
   }

   Wrapping both struct initializers in init! (or putting init in front in this proposal) will result in them being initialized in-place (of course this changes the return type to impl Init<Struct2>).