RFC: moving forward with @nogc Phobos

[via Digitalmars-d]

On Thursday, 2 October 2014 at 19:45:17 UTC, Ola Fosheim Grøstad 
wrote:
> But is sketchy on implementation details, semantic restrictions 
> that follows and consequences when interacting with foreign 
> code etc.

Some Rust details. «sendable» means that a reference can be 
transferred to another thread (or task/fiber/whatever).

 From http://doc.rust-lang.org/std/gc/ :

«The Gc type provides shared ownership of an immutable value. 
Destruction is not deterministic, and will occur some time 
between every Gc handle being gone and the end of the task. The 
garbage collector is task-local so Gc<T> is not sendable.»

 From http://doc.rust-lang.org/std/rc/index.html :

«The Rc type provides shared ownership of an immutable value. 
Destruction is deterministic, and will occur as soon as the last 
owner is gone. It is marked as non-sendable because it avoids the 
overhead of atomic reference counting.

The downgrade method can be used to create a non-owning Weak 
pointer to the box. A Weak pointer can be upgraded to an Rc 
pointer, but will return None if the value has already been 
freed.»

So… they don't really solve the issues a @nogc version of D 
should be able to deal with beyond having built-in unique_ptr 
style semantics?

Or?