Tracking Issue for `const_box`

[lilasta]

Feature gate: #![feature(const_box)]

This is a tracking issue for implementing const Box<T, A> methods.

Public API

impl<T, A: Allocator> Box<T, A> {
    pub const unsafe fn from_raw_in(raw: *mut T, alloc: A) -> Self;
    pub const fn allocator(b: &Self) -> &A;
    pub const fn into_pin(boxed: Self) -> Pin<Self>
    where
        A: 'static;
}

Steps / History

• Implementation: Constify Box<T, A> methods #91884
• Final comment period (FCP)
• Stabilization PR

Unresolved Questions

• None

[beepster4096]

The non-ZST allocator issue has been resolved and should be removed from the unresolved questions list.

[lilasta]

Thanks for the information. I've removed it.

[rinarakaki]

I'm sorry for my shallow understanding, but can't Clone be constified for Box<T> at the same time?

[chorman0773]

Aparently it is possible on stable to Deref Box in a const-fn: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=52526e62eba8e2846bfcc45bdb04f47e

Was this intentional?

[lilasta]

I'm sorry for my shallow understanding, but can't Clone be constified for Box at the same time?

Currently it cannot. Rust's specialization doesn't yet support const-impl enough, so some Copy specializations will cause a compilation error. (Or we have to mark Copy as #[const_trait])
Example: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=eab0289f5fc7537133a8df4ac6449323

rust/library/alloc/src/alloc.rs

Lines 424 to 443 in 8c0f83d

	pub(crate) trait WriteCloneIntoRaw: Sized {
	unsafe fn write_clone_into_raw(&self, target: *mut Self);
	}
	impl<T: Clone> WriteCloneIntoRaw for T {
	#[inline]
	default unsafe fn write_clone_into_raw(&self, target: *mut Self) {
	// Having allocated *first* may allow the optimizer to create
	// the cloned value in-place, skipping the local and move.
	unsafe { target.write(self.clone()) };
	}
	}
	impl<T: Copy> WriteCloneIntoRaw for T {
	#[inline]
	unsafe fn write_clone_into_raw(&self, target: *mut Self) {
	// We can always copy in-place, without ever involving a local value.
	unsafe { target.copy_from_nonoverlapping(self, 1) };
	}
	}

Aparently it is possible on stable to Deref Box in a const-fn
Was this intentional?

This behavior is not caused by this feature. It can be reproduced in pre-1.58.0. It may be due to the compiler's special DerefMove behavior.

[RalfJung]

This feature has been mostly removed by #110393, and anyway const_heap is still extremely experimental. Do the remaining methods make any sense to keep or should we just scratch this entirely for now?

[lilasta]

@RalfJung I believe there's little point in keeping the remaining methods. Would it be all right if I create a PR for the removal? As for #92523, I also plan to remove const and close it.

[RalfJung]

That makes sense for me -- @rust-lang/wg-const-eval what do you think?