[eq-]

I wonder if there's a (simple syntactical) way to unlink the constness of unique pointers and their targets. It's not a huge obstruction, but seems like an unnecessary restriction not found in the near-equivalent C++ construction.

[pcwalton]

Yes, you can do it, with Cell and RefCell, though the former is restricted to POD types and the latter comes with some minor runtime overhead.

Inherited mutability is not an unnecessary restriction from the point of view of memory safety. It's critical to Rust's ability to prevent iterator invalidation and related bugs at compile time. The fact that C++ doesn't do it is the source of many of its memory safety problems, such as dangling references and iterator invalidation.

[pohl]

the former is restricted to POD types

I had to look this acronym up. In case anybody else needs a definition:

https://en.wikipedia.org/wiki/Plain_Old_Data_Structures

[gilgoomesh]

Within context (the article is for C++ programmers) POD is a commonly used acronym.

If you're a C++ programmer and don't know about POD types (data types with zero implicit C++ behaviors), you should brush up on your fundamentals – it's essential to understand when and why C++ behaviors (i.e. behaviors above and beyond plain C) are invoked implicitly.

[Peaker]

I was a bit surprised by the reverse:

  let x = 5
  let mut y = &x

If I understood correctly, x is immutable, but can still be mutated via (*y)?

[pcwalton]

No, that results in an error. Mutability doesn't inherit through references (`&`).

[coderjames]

[disclaimer: still learning Rust]

I believe it actually means that y can be made to reference something other than x.

  let x = 5
  let mut y = &x
  let i = 13
  y = &i

This is similar to C++'s const-pointers and pointers-to-consts, where either a pointer cannot be made to point at something different or the pointer cannot be used to change what it points at.

[FreeFull]

That actually lets you change what y points at, but you can't mutate x through y. If you want to mutate x, you need something like

    let y = &mut x;

which will result in an error due to x not being mutable.

[steveklabnik]

I'm not sure what you mean about unique pointers and const-ness. Can you explain? You can make unique pointers mutable:

    fn main() {
        let mut x = ~5;
        *x = *x + 1;
        println!("{:d}", *x);
    }

Or did you mean something else?

[ndeine]

He means immutability when he says "const-ness". There are four possibilities for mutability of a single pointer:

1. The pointer is mutable, but its contents are immutable.

2. The pointer is immutable, but its contents are mutable.

3. The pointer is immutable and the contents are immutable.

4. The pointer is mutable and its contents are mutable.

Right now for owned pointers Rust gives us (3) and (4), but no obvious way to achieve (1) and (2). Although you might argue that the borrowing semantics give us these powers, just not directly with owned pointers - which we shouldn't be using directly if we're asking for that control, we should be lending them out in a well-controlled manner.

[pcwalton]

You can use privacy for (1); admittedly it's a little hokey, but I feel it's not worth the added complexity to add field-level immutability directly into the language since you can use other language features to effectively achieve it. `std::cell::Cell` and `std::cell::RefCell` give you (2).

[azth]

> `std::cell::Cell` and `std::cell::RefCell` give you (2).

What advantages does (2) provide? Isn't it a potential source of errors?

[pcwalton]

It is, but sometimes you have to do it for practicality. Usually this comes up when people use `Rc<T>`, as that only supports immutable types (so any mutability you want needs to be in the form of `Cell`/`RefCell`).

[azth]

Would it be better to combine both types (e.g. a MutRc<T> type), and get rid of Cell/RefCell?

[steveklabnik]

Ahh, thank you. And yes, that's what I'd argue.

[ben0x539]

I'm usually pretty happy that ~T works just like T in terms of ownership and mutability and move-semantics and whatnot. When would you want to unlink that?