Experiment proposal: In-place initialization

[compiler-errors]

Experiment: In-place initialization

A few weeks ago, @Darksonn authored https://hackmd.io/@aliceryhl/BJutRcPblx that proposes the lang-ification of the pin-init crate, and how it can be used to enable and simplify some major use-cases in the language. The motivation in that doc is pretty thorough, so I won't copy it over here and I encourage you to read it to understand the background.

I think that the design, modulo syntax, is clear enough that it would be worthwhile to experiment with the implementation in the compiler. This is particularly important because I think we'll both learn a lot about the design from the implementation in the compiler, and because the implementation in the compiler will likely need to go through a few iterations¹ that can happen in parallel with any evolution of the syntax.

I'm opening up a lightweight experiment proposal here in the T-lang repo just for bookkeeping. I wasn't totally sure whether to open this in the lang team repo as an experiment proposal, or on the r-l/r repo as a feature gate tracker. But since no PRs have been opened up yet, I wanted to open this here first. I assume a feature gate issue in the compiler will follow soon.

After syncing this morning, @dingxiangfei2009 is first planning on opening a PR to add the trait Init<T> to the standard library for experimentation, and then in parallel @dingxiangfei2009 will be working on the implementation of user-written init Struct { .. } expressions, and I'll be working on the feature's interaction with AFIDT (async fn in dyn trait, cc rust-lang/rust#133119).

As is true with all lang experiments, this feature is subject to change and removal with no guarantees, and I assume an RFC will follow in due time, hopefully better informed due to experimentation in the compiler impl.

---

Some relevant contacts:

Design: @Darksonn @y86-dev
Implementation: @dingxiangfei2009, @compiler-errors
Compiler team liaison/reviewer: @compiler-errors
Lang liaison: @joshtriplett

If I've missed cc'ing someone, let me know. If you don't want to be recorded here, let me know too.

Footnotes

1. Adding a new closure-ish type to the compiler requires touching tons of places in the compiler, and IMO it's worth surfacing all of the interactions sooner than later! ↩

[compiler-errors]

There's a meeting (#332) scheduled for 2025/07/30, but given that's in more than a month, I'm hopeful we'll have gathered some signal from implementation to give back to that meeting :)

[BennoLossin]

cc @nbdd0121

[joshtriplett]

Looks good to me. Seconded, and confirming that I would be happy to be the liaison/champion.

[Diggsey]

This seems like an interesting direction to explore. The main downside I see is that dyn Trait no longer implements Trait.

I think this could be resolved. First, add support for returning impl Trait + use<> from a dyn-safe trait method:

trait Foo {
    fn foo(&self) -> impl MyTrait + use<>; // dyn safe
}

This is dyn-safe because the use<> syntax means the return type does not vary with the Self type.

Next, we can use this mechanism to make the anonymous PinInit struct more explicit. Instead of specifying say impl Future as the return type of a trait method, we can write this, which is dyn-safe due to the above rule:

trait Foo {
    fn foo(&self) -> impl PinInit<dyn Future<Output=()>> + use<>;
}

This syntax is a bit verbose, so we can introduce sugar such as:

trait Foo {
    fn foo(&self) -> init Future<Output=()>>;
}

When implementing the trait with this sugar, one just returns the future normally:

impl Foo for MyStruct {
    fn foo(&self) -> init Future<Output=()>> {
        async {
            // do a thing
        }
    }
}

With async sugar, this further becomes:

impl Foo for MyStruct {
    async fn foo(&self) {
        // do a thing
    }
}

With this approach, Foo can still be used as a bound on dyn Foo.

[BennoLossin]

This is dyn-safe because the use<> syntax means the return type does not vary with the Self type.

I might not understand use<> too well yet, but how would this work? This would require every instance of Foo::foo to return the same type? That won't work, since the initializer depends on the function's contents.

Also I don't think this is the right place for a discussion (correct me if I'm wrong), so maybe let's take this to zulip? feel free to tag me there

[Diggsey]

👍 https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/In-place.20initialization.20.60use.3C.3E.60.20discussion/with/525234268

[mqudsi]

This would bring us a lot closer to supporting the creation of unsized locals and dynamically sized types in safe, idiomatic rust, no?

[xmh0511]

By looking at the blanket implementation of PinInit and try_pinit in Box<T>

unsafe impl<T> PinInit<T> for T {
    type Error = Infallible;

    fn init(self, slot: *mut T) -> Result<(), Infallible> {
        slot.write(self);
        Ok(())
    }

    fn layout(&self) -> Layout {
        Layout::new::<T>()
    }
}

impl<T> Box<T> {
  //....

 
    pub fn try_pinit<E>(i: impl PinInit<T, Error = E>) -> Result<Pin<Box<T>>, E> {
        let mut me = Box::<T>::new_uninit();
        i.init(me.as_mut_ptr())?;
        Ok(Pin::from(me.assume_init()))
    }
}

me.as_mut_ptr() returns * mut T, and i.init(me.as_mut_ptr()) will call PinInit::init, the default implementation calls slot.write(self);, this implies self must be of type T, doesn't it mean the value of type T still need to be firstly constructed on the stack?

[traviscross]

The design document for this assumes a pin ergonomics / pin projection design that uses #[pin] field annotations rather than the type-based approach (similar to MinPin) that we've been pursuing with the pin ergonomics work under that lang experiment (tracking).

On the lang/RfL call last week (minutes), @Darksonn, @BennoLossin, and I talked this through. I later talked through the in-place initialization work and this discrepancy with @frank-king and @eholk who are doing the work on pin ergonomics. @frank-king is planning to write out a design document in the coming weeks.

I mention this here just for documentation, and so we all remember to keep talking with each other given that the experiments overlap in this way.

cc @rust-lang/lang @frank-king @eholk

[Aloso]

@xmh0511

me.as_mut_ptr() returns * mut T, and i.init(me.as_mut_ptr()) will call PinInit::init, the default implementation calls slot.write(self);, this implies self must be of type T, doesn't it mean the value of type T still need to be firstly constructed on the stack?

Yes but only if this blanket implementation impl<T> PinInit<T> for T is used. init expressions will desugar to a different impl with a compiler-generated initializer containing the initializers of all the fields. impl trait in dyn Trait will have yet another desugaring with an initializer containing the function arguments. This initializer will call the actual trait method from its init method.

[traviscross]

As I understand, @cramertj is separately also working on a proposal for in-place initialization using out pointers. We'll want to make sure we all keeping talking here as well, in particular leading up to the design meeting scheduled for 2025-07-30.

cc @cramertj @tmandry @tomassedovic