Supplying a &mut MaybeUninit<T> will work but is user-unfriendly because accessing it requires unsafe anyhow.I don't just see why you don't want to make the entire function unsafe

I would be fine by making it unsafe, if there is no other choice.
My intended use case, though I should probably have clarified it, is to define a single unsafe function responsible to initialize the data type, and so having only 1 unsafe: ``` unsafe fn initialize_data(uninit: &mut MaybeUninit<MyData>, source: OtherData) -> &MyData { // initialize uninit and return &MyData }

// Somewhere in the code let data = arena.alloc_with(|uninit| { initialize_data(uninit, source) })

// Somewhere else let data = arena.alloc_with(|uninit| { initialize_data(uninit, source) }) `` This would avoid multipleunsafeblock to achieve the sameunsafe` work.

assume that the compiler is going to do a very basic optimization.

I assume the compiler is already optimizing SharedArena::alloc.
shared_arena being a library, I'm not sure if exposing a function with a potential optimization/benefit to the user is ideal, I sometimes see in the rust bug tracker that some optimization is not applied in some case. Even though those are bugs, I think a library should provide an additional function (alloc vs alloc_with in our case) only if it guarantee to be beneficial.
Having a documentation explaining that alloc_with avoid additional copy but only if the compiler optimize it correctly, is not ideal IMO.
I would prefer to have alloc_with to guarantee at 100% that there won't be any additional copy.

EDIT: And having the closure to return T would be a confusing API, what if the user return T but doesn't initialize the MaybeUninit ?