Smart pointers instead of GC?

[Adam Wilson]

On Sat, 01 Feb 2014 18:16:07 -0800, Frank Bauer <y at z.com> wrote:

> Agreed. We must keep the GC in D and not change its semantics (certainly  
> its performance to be sure).
>
> I would not even want to go the Rust way (their latest anyway, it keeps  
> changing, mostly for the better) of relegating the GC to a library type  
> Gc<T>. It should remain part of the language for the majority of  
> developers who benefit from it.
>
> Again, I agree, making life harder for people who wish to use GC would  
> not be acceptable. I enjoy the GC for non-critical apps.
>
> What I am for is an opt-in solution for GC, not necessarily, as the OP  
> implies, favoring smart pointers over GC, but for both being on an equal  
> footing.
>
> Let developers who strive for ultimate performance choose their tool and  
> let D set the standard for what is possible with a modern language.
>
> It might be a minority issue overall, but a significant one here in  
> these forums, from what I gather.
>
> The D implementers will decide if the two ways of memory management can  
> be reconciled and if it's worth the effort. +1 from me on both.

I am for that as well. GC by default, then opt-in to other semantics, even  
if via new syntax. That will give the flexibility to do what you need to  
do when you need to do it without significantly increasing the costs to  
the common use case... THAT is a laudable position to take. And I'll  
happily root for support different resource management paradigms, because  
the one truth is that there is no one right way. But as soon as I start  
seeing arguments along the lines of "X is stupid because it doesn't work  
for my use case so we must replace it with Y" I'll start fighting.

-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator