On Monday, 3 June 2013 at 16:47:35 UTC, Rob T wrote:
> On Monday, 3 June 2013 at 16:01:29 UTC, H. S. Teoh wrote:
>
> C++11 deprecated auto_ptr in favor of unique_ptr, but it's basically the same concept, and it works very well in cases where you prefer to manage your own memory. D should have the same thing in the std lib, it's not difficult to implement. The ref counted pointers are another similar thing, a bit more difficult to implement correctly and there's a circular ref issue with them.
>

There is this: http://dlang.org/phobos/std_typecons.html#.Unique  I can't comment how good it is though.

On Monday, 3 June 2013 at 16:47:35 UTC, Rob T wrote:
> Also a better GC in no way invalidates the need for other memory management schemes because there will always be situations where a GC is not an appropriate solution, at least not until someone invents the perfect one size fits all GC.

phobos has Unique http://dlang.org/phobos/std_typecons.html#.Unique and RefCounted http://dlang.org/phobos/std_typecons.html#.RefCounted

On Monday, 3 June 2013 at 18:10:50 UTC, Kagamin wrote:
> On Monday, 3 June 2013 at 16:47:35 UTC, Rob T wrote:
>> Also a better GC in no way invalidates the need for other memory management schemes because there will always be situations where a GC is not an appropriate solution, at least not until someone invents the perfect one size fits all GC.
>
> phobos has Unique http://dlang.org/phobos/std_typecons.html#.Unique and RefCounted http://dlang.org/phobos/std_typecons.html#.RefCounted

RefCounted notably does not work with classes yet (just because no one has taken the time to add support).

On 4 June 2013 03:41, Paulo Pinto <pjmlp@progtools.org> wrote:

> Am 03.06.2013 18:00, schrieb Manu:
>
>  Haha, wow. Indeed, isn't that well timed with respect to recent
>> discussions! ;)
>> Post-dconf, I gave it some serious thought and I'm kinda convincing
>> myself more and more each day that it's the way to go.
>>
>>
> As I mentioned I prefer GC based solutions, but then again I live in the JVM/.NET world, so I don't have the memory/timing pressure you have to deal with.
>

I don't expect the GC would go anywhere. It would remain in use in typical
computing environments.
It would just be an option for realtime users/embedded platforms.

But when looking at systems programming languages that offer reference
> counting as the main memory management, ATS, Parasail, Objective-C, and now Rust, all of them share a common feature:
>
> - Compiler support to remove extra increment/decrement operations.
>
> I guess on D's case this support would also be required.
>

Yeah, indeed. I have no idea how much work that would be. I'm not holding my breath that it'll appear any time soon :)

On 06/03/13 12:41, Paulo Pinto wrote:
> Am 03.06.2013 18:00, schrieb Manu:
>> Haha, wow. Indeed, isn't that well timed with respect to recent
>> discussions! ;)
>> Post-dconf, I gave it some serious thought and I'm kinda convincing
>> myself more and more each day that it's the way to go.
>>
> 
> As I mentioned I prefer GC based solutions, but then again I live in the JVM/.NET world, so I don't have the memory/timing pressure you have to deal with.
> 
> But when looking at systems programming languages that offer reference counting as the main memory management, ATS, Parasail, Objective-C, and now Rust, all of them share a common feature:
> 
> - Compiler support to remove extra increment/decrement operations.
> 
> I guess on D's case this support would also be required.
> 
> -- 
> Paulo
> 

IIUC, a system programming language would use threading at least a fair amount.  In that case, I'm not sure reference counting is appropriate, at least according to the following:

.> However, I think you are also talking about RC in multi-threaded
.> (not distributed) systems. Here, the cost of making RC thread-safe
.> (both RC and pointer manipulations must be atomic) can be expensive
.> if done naively. It's worth taking a moment to think about
.> this. Consider a scenario with 3 objects, A, B and C, and two
.> threads, T1 and T2. Suppose that T1 writes a reference to B into a
.> slot in A and T2 writes a reference to C into the same slot. (You
.> can say that such a program is broken but memory managers but cope
.> with broken code). Both the reference count operations and the
.> pointer updates must be synchronised so that the reference counts
.> do reflect the final state of the reference held in A. This is
.> prohibitively expensive if used for general memory management
.> (i.e. rather than just for managing a few special objects).

This is from a private email(which Jones said I could forward to c.l.c++.m, which, I assume means I can quote here also):

.> Date: Fri, 15 Apr 2005 10:50:50 +0100
.> From: Richard Jones <R.E.Jones@kent.ac.uk>

Of course maybe RC has improved since 2005.  I'm no expert :(

-regards,
Larry

Interesting read on the subject of ARC and GC: http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/

It does seem that ARC would be a preferred strategy for D to pursue (even if it's a first pass before resorting to GC sweeps).

Opps, just saw that this link was already posted here:
http://forum.dlang.org/thread/krhjq8$2r8l$1@digitalmars.com