
The Problem With Single-threaded Shared Mutability - Manishearth
http://manishearth.github.io/blog/2015/05/17/the-problem-with-shared-mutability/
======
sumith1896
Coming from a guy who has no idea of Rust, and since we are talking about
memory safety. In a c++ library, we use RCP (reference counted pointers) which
dis-allocates on it's own, so we never call naked delete. Does such a thing
exist in Rust pointers, because this memory safe feature I'd love to have!

~~~
LeafStorm
Rust has two types called Rc and Arc that have this behavior. When you clone
an Rc pointer, the internal reference count increments, and as each clone
disappears, the reference count decrements. (Arc works like Rc, but it uses
atomic increment and decrement operators, so you can share it across threads.)

Rc: [http://doc.rust-lang.org/stable/std/rc/struct.Rc.html](http://doc.rust-
lang.org/stable/std/rc/struct.Rc.html)

Arc: [http://doc.rust-
lang.org/stable/std/sync/struct.Arc.html](http://doc.rust-
lang.org/stable/std/sync/struct.Arc.html)

~~~
marijn
... but most of the time you don't need them, because the single-ownership (+
multiple read-only borrowers) model built into the type system already does
what you need. There is no 'naked delete' in Rust, deletes are implicitly
inserted by the compiler at the point where the owner of a piece of memory
lets it go out of scope.

------
th0br0
Reading such comments on Rust I'm always wondering: are there any plans to
make parallel execution a core feature of Rust? Given the safety information
that the compiler generates, it should be relatively straightforward to
offload "pure" functions to other processors. (Although AFAIR Rust actually
had the notion of pure functions initially but dropped it after some time)

~~~
Manishearth
Not that I know of.

Yes, Rust had purity, then it went away. There are some plans for constexpr-
like support which may bring back some purity-like support.

Being a systems language unpredictably using threads sounds like a no-no to
me. But I wonder if this could be designed as a compiler plugin or something.

~~~
schuyler3d
How would purity be different in Rust than any function signature without any
&mut?

~~~
GolDDranks
Rust functions can still have side effects: they can access unsafely global
variables and read them even without unsafe access. They can call libraries
that do IO. I.e. they are not referentially transparent.

Constexp would be pure, because they can't rely on ANY external state, in
order to be const.

~~~
schuyler3d
OK, fair enough, but it still seems like the rust compiler has enough
information to determine whether something is a pure function. It knows
whether global or enclosed variables are present and it knows if any of the
methods it calls have an &mut ref, which I think is needed even for IO reading

~~~
GolDDranks
Yeah, I think the compiler has enough information to do that, in principle.
But there is another problem: Rust has the design principle that every
language-enforced invariant should be clear just from the function signature.
This has at least two benefits: the compiler doesn't have to reason about the
code invariants "globally", which might slow and hard to optimize, and the
APIs are clearer and the user doesn't have to know implementation details to
reason about them.

If there's going to be some concept of purity, according to the same
principle, it'd be something that one could know just by looking at the
function signatures.

