Comment by aw1621107

2 days ago

> Like why do I need to use `addr_of_mut!`?

As of Rust 1.82.0 [0] you no longer need to!

> I'm sure there's a good reason, as Rust tends to think these problems through, but it's very unintuitive compared to returning `&mut`.

The addr_of_mut docs [1] give a pretty decent explanation of its reason for existence; in short, it lets you get a pointer to something without needing to create potentially-invalid intermediate references. It (and &raw) probably aren't going to be needed if all you need is a &mut, though.

> Does cordyceps have a derive macro?

Doesn't appear to from a quick glance, and given what's in the safety section of the docs [2] it'd probably need to be marked unsafe [3]. Unsafe attributes are new to Rust 2024, though, so that might be a bit new.

[0]: https://blog.rust-lang.org/2024/10/17/Rust-1.82.0/#native-sy...

[1]: https://doc.rust-lang.org/std/ptr/macro.addr_of_mut.html

[2]: https://docs.rs/cordyceps/latest/cordyceps/trait.Linked.html...

[3]: https://doc.rust-lang.org/edition-guide/rust-2024/unsafe-att...

> > Like why do I need to use `addr_of_mut!`?

> As of Rust 1.82.0 [0] you no longer need to!

That's true but misleading. I'm pretty sure the question was why a normal reference is bad. You don't need `addr_of_mut!()`, but you do need `&raw mut`.

  • > I'm pretty sure the question was why a normal reference is bad.

    Oh, completely missed that interpretation. I think in that case it comes down to references being incompatible with the desired semantics for an intrusive list - & doesn't work if you want to modify what you're pointing to, and &mut doesn't work since you may want multiple things to be able to point to and modify whatever you're pointing to.

So how do I take a shared reference to a variable named "raw"?

Complicating the grammar for no good reason. This should have stayed a macro.

Interesting. I stopped working with Rust about two years ago, so it looks like there's been a lot more polish in these areas.