On Sat, 01 Feb 2014 18:16:07 -0800, Frank Bauer <[email protected]> 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
