This got reverted again by #86003, but hopefully we can re-land it soon.

@pnkfelix I don't quite understand why you un-constified swap... it seems write is the underlying source of the problem. Does it not work to add the const stability attribute here?

I have reverted the constness reverts in #86295

I've filed #90644 to extend the const_swap feature to three more functions. Some of them can panic, but const_panic is stable as of #89508. Edit: seems that std library functions need #90687 on top of const_panic stabilization. I expect that PR gets merged quite soon.

This should be blocked on const mut refs, I believe.

The following code used to work with swap_nonoverlapping, but doesn't any more:

#![feature(const_swap)]
#![feature(const_mut_refs)]
use std::{
    mem::{self, MaybeUninit},
    ptr,
};

const X: () = {
    let mut ptr1 = &1;
    let mut ptr2 = &2;

    // Swap them, bytewise.
    unsafe {
        ptr::swap_nonoverlapping(
            &mut ptr1 as *mut _ as *mut MaybeUninit<u8>,
            &mut ptr2 as *mut _ as *mut MaybeUninit<u8>,
            mem::size_of::<&i32>(),
        );
    }
    
    // Make sure they still work.
    assert!(*ptr1 == 2);
    assert!(*ptr2 == 1);
};

That is a regression introduced by the new implementation of swap_nonoverlapping in #94212. Though arguably it is a mere coincidence that the previous implementation worked: this is fundamentally caused by a limitation of compile-time evaluation. We have no good way to represent a 'part' of a pointer, so we cannot work on pointers bytewise. Changing the above code to copy a single &i32 rather than 8 MaybeUninit<u8> fixes it.

Not being able to work bytewise on pointer is a general limitation of CTFE, so we could document this as such. However, note that copy and copy_nonoverlapping actually work here; this is because they are implemented via intrinsics which then do copy the entire memory range at once, thus not having to deal with pointers bytewise.

So... we could easily stabilize ptr::swap once #129195 lands, but ptr::swap_nonoverlapping has a serious limitation currently where it can fail when the data-to-swap contains pointers that cross the "element boundary" of such a swap. (The key difference here is that ptr::swap_nonoverlapping takes a count parameter, but ptr::swap only ever swaps a single element.)

Fixing this requires either an intrinsic for swapping (maybe only used by const-eval), or using const_heap... we have to allocate enough space to do the 3-copy version of swapping, as the more efficient "progressive" swapping is exactly what causes the problem.

Here's the test for this:

#[test]
fn test_const_swap() {
    const {
        let mut ptr1 = &1;
        let mut ptr2 = &666;

        // Swap ptr1 and ptr2, bytewise.
        unsafe {
            ptr::swap_nonoverlapping(
                ptr::from_mut(&mut ptr1).cast::<u8>(),
                ptr::from_mut(&mut ptr2).cast::<u8>(),
                mem::size_of::<&i32>(),
            );
        }

        // Make sure they still work.
        assert!(*ptr1 == 666);
        assert!(*ptr2 == 1);
    };

    const {
        let mut ptr1 = &1;
        let mut ptr2 = &666;

        // Swap ptr1 and ptr2, bytewise. `swap` does not take a count
        // so the best we can do is use an array.
        type T = [u8; mem::size_of::<&i32>()];
        unsafe {
            ptr::swap(
                ptr::from_mut(&mut ptr1).cast::<T>(),
                ptr::from_mut(&mut ptr2).cast::<T>(),
            );
        }

        // Make sure they still work.
        assert!(*ptr1 == 666);
        assert!(*ptr2 == 1);
    };
}

Just to comment on this, but swap would be useful to const-stabilise now even if swap_nonoverlapping takes a bit longer, since it would simplify code that has to do a manual 3-way swap a lot.

Feel free to make a PR that proposes stabilizing ptr::swap. :)

After today's 1.83.0 release this is no longer blocked on const_mut_refs .

@rust-lang/libs-api I propose that we const-stabilize all of the above mentioned functions except for swap_nonoverlapping. The problem with swap_nonoverlapping is that it takes a count: isize parameter, and is described as an "untyped" operation acting on count * size_of::<T>() bytes, but the const-implementation currently acts count times on chunks of size_of::<T>() bytes, and that is not the same when there is a pointer that is partially contained in multiple chunks, but wholly contained in the entire large range.

ptr::swap has no count parameter, so there is no similar problem there. And all the other methods can be implemented with ptr::swap.

@rfcbot fcp merge

• https://doc.rust-lang.org/nightly/core/ptr/fn.swap.html
• https://doc.rust-lang.org/nightly/core/mem/fn.swap.html
• https://doc.rust-lang.org/nightly/core/primitive.slice.html#method.swap
• https://doc.rust-lang.org/nightly/core/primitive.pointer.html#method.swap
• https://doc.rust-lang.org/nightly/core/ptr/struct.NonNull.html#method.swap

Leaving out core::ptr::swap_nonoverlapping for now per the recommendation in #83163 (comment).

Lastly there is <[_]>::swap_unchecked which is still unstable. Let's move its const stability out of this issue to be tracked as part of #88539 instead.

Team member @dtolnay has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

Lastly there is <[_]>::swap_unchecked which is still unstable. Let's move its const stability out of this issue to be tracked as part of #88539 instead.

Oh, good catch, I missed that.

I will file a PR to move swap_unchecked and swap_nonoverlapping to separate feature gates.

EDIT: PR is up at #133669.
As part of that I also created #133668 to cover const swap_nonoverlapping.

@Amanieu @BurntSushi @joshtriplett @m-ou-se FCP checkbox reminder. :)
This const-stabilizes some stable fn that could already be (unsafely) implemented in terms of other stable const fn, so it's a fairly straight-forward extension of our const API surface.

🔔 This is now entering its final comment period, as per the review above. 🔔

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.