Adding functions to temporarily take ownership of a mutable reference to std::mem

[197g]

@ryanavella

This would infect the call signature up to the level where you diverge, I suppose? So it is just as infectious as rewriting everything from fn(&mut T, ..) -> .. to fn(T, ..) -> (T, ..).

That rewrite is inaccurate since different &mut T arguments can be used on disjunct places while tuples will introduce its own places (and necessitate more moves). So while it is similarly infections at least the guard version is semantically close to the intent of taking ownership from mutable arguments. A guard may work better with init expressions in the sense of composing rather than also leaking the re-initialization method but it is quite early and I've not followed that implementation too closely to say for sure.

[josh]

@dlight

Oh, uuh, it would be nice to specify that some attribute macro is unsafe, that is, if you use the proc macro you are opting in into a more narrow set of constraints. And then use it as #[unsafe(my_macro)]

This is possible with declarative attribute macros on nightly.

[CAD97]

@ryanavella

When combined with the safe subset of Rust, partial_borrow and replace_with are each sound in isolation, but they do not compose soundly.

FWIW, replace_with is also unsound in combination with the Nomicon's recommended way of representing opaque FFI types. The correct solution to both is for extern type to become a thing that can't be owned by value.

It's also a pain for mem::swap, which biases me towards ZST "fakes" being a cute trick but breaking standard Rust assumptions.

Disclaimer: I am a member of the UCG and T-opsem, but am speaking solely for myself, not the team(s).

[ryanavella]

What exactly is unsound, do you have an example in mind? If the C type is opaque and the Rust representation is (as an implementation detail) a ZST, then obtaining ownership doesn't seem particularly useful to me. Especially if all of the APIs operate on [*mut|&mut] Opaque instead of Opaque.

[CAD97]

@ryanavella

What exactly is unsound, do you have an example in mind? If the C type is opaque and the Rust representation is (as an implementation detail) a ZST, then obtaining ownership doesn't seem particularly useful to me.

Except now any code using &Opaque now thinks the address is of your owned value, not the address that the FFI code handed out and is expecting to get back.

[gdennie]

Without modifying your data structure the following seems sufficiently elegant.

fn push_front(&mut self, x:T) {
  *self = Self::Cons((x, std::mem::replace(self, Self::Nil)).into());
}

and for a bit more clarity...

fn push_front(&mut self, x:T) {
  let default = Self::Nil;
  let current_head = std::mem::replace(self, default);
  *self = Self::Cons((x, current_head).into())
}

The fact a valid value must always exist in the target of a reference makes the std::mem module more important than the documentation would suggest, at least back when I read it many moons ago.

[ryanavella]

@CAD97

FWIW, replace_with is also unsound in combination with the Nomicon's recommended way of representing opaque FFI types. The correct solution to both is for extern type to become a thing that can't be owned by value.

Thinking about this some more, the Nomicon only recommends *mut Opaque, it does not say anything about &mut Opaque.

If references are desired over raw pointers, then Pin<&mut Opaque> better expresses the intent that opaque structs cannot be moved (except through blessed FFI escape hatches) and can not be created on the stack by downstream users.

[steffahn]

@gdennie

Without modifying your data structure the following seems sufficiently elegant.

fn push_front(&mut self, x:T) {
  *self = Self::Cons((x, std::mem::replace(self, Self::Nil)).into());
}

and for a bit more clarity...

fn push_front(&mut self, x:T) {
  let default = Self::Nil;
  let current_head = std::mem::replace(self, default);
  *self = Self::Cons((x, current_head).into())
}

That’s basically just a more convoluted way of doing the following^[1], isn’t it?

@steffahn

I mean, for this particular example, you could already just do something like the following, right?

use std::mem;

#[derive(Default)]
enum List<T> {
    #[default]
    Nil,
    Cons(Box<(T, List<T>)>),
}

impl<T> List<T> {
    fn push_front(&mut self, x: T) {
        *self = Self::Cons((x, mem::take(self)).into())
    }
}

though I guess, yours might be the “right” way if – for whatever reason – a Default implementation wasn’t actually desired ^^

---

1. and not really an improvement over what’s already mentioned in this thread ↩︎

[gdennie]

Your approach to introducing a default variant aligns with my personal preference. I like to embed as many constraints as possible directly into the type definitions, thereby centralizing them in a definitive way.

My post was primarily instructional in nature. In particular, I hadn’t fully appreciated the importance of the std::mem module in working within the constraints imposed by Rust’s ownership model.