Smart pointers instead of GC?

[Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com>]

On Tuesday, 4 February 2014 at 22:17:40 UTC, Steven Schveighoffer 
wrote:
> This is an important point. However, the default is to be safe, 
> and good enough for most.

Yes, absolutely. I am all for progressive refinement, starting 
out with something conceptual  and very close to pseudocode, with 
all the convenience of high level programming. Then replace the 
parts that does not perform.

In Objective-C you don't really care that much about performance 
though, Cocoa provides very versatile libraries doing a lot of 
the work for you, but you have to go one step down to get speed 
without libraries. Inefficiencies are less noticeable in a heavy 
library/premade-components environment like Cococa than in a more 
barebones hit-the-iron-C-like approach.

> One could also say you could mark a memory region as no-scan if 
> you know that the data it points at will never be collected for 
> its entire existence in a GC environment.

Yes, I agree. You could have the same type in different pools and 
mark one of the pools as no-scan. You could have pool-local 
GC/segmented GC or even type-limited GC with whole program 
analysis (only collecting a specific class/subclasses).

> I think some mix of GC and ref counting for D would be 
> extremely useful.

Yes, I don't want to throw out GC, but I think it would be more 
valuable and more realistic to have C++ reference semantics than 
advanced compiler inferred ARC, though I don't mind ARC, I think 
it probably is harder to get right for a more pure C systems 
level language than for Objective-C with Cocoa.

So, I think ARC is right for Cocoa, but not so sure about how 
well it works in other environments.