D 2015/2016 Vision?

[Namespace via Digitalmars-d]

> Language-supported ref-counting wouldn't fix that. As long as 
> you're allowed to put a ref-counted object inside of a 
> GC-managed object, it's possible that the GC will ultimately 
> managed the lifetime of your ref-counted object - or even that 
> it will never be destroyed, because it simply isn't collected 
> prior to the program shutting down. And it's not like we're 
> going to make it illegal to put a ref-counted object inside of 
> a GC-managed object. That would be needlessly restrictive. 
> Ultimately, programmers simply have to be smart about what they 
> do with objects on the GC heap if deterministic destruction is 
> required.
>
> Having ref-counting built into the language will allow us to 
> make it more efficient and provide some safety guarantees that 
> can't necessarily be provided in a struct, but it doesn't make 
> it so that no one can misuse ref-counted objects.
>
> Ultimately, the largest benefit to having ref-counting built 
> into the language will probably be that we can the have 
> exceptions be reference counted - and maybe even make it so 
> that they're malloced normally so that they can be used in 
> @nogc code. Most of the benefits of ref-counting can already be 
> done with structs.
>
> - Jonathan M Davis

Sure, there are, of course, still ways to avoid the guarantees. 
But it's more likely that others write A a = new A("Hello"); 
instead Unique!A a = unique!A("Hello"); so we increase the 
probability that others get it right.