On 9/19/14, 11:15 PM, Walter Bright wrote:
On 9/19/2014 10:46 PM, Andrei Alexandrescu wrote:
2. To deal with (1), existing ARC systems allow escapes from it. This
has severe implications for memory safety. Rust's entire type system
appears to be designed around trying to deal with this, and AFAIK
they're the only ones who have tried. C++ shared_ptr and ObjectiveC's
ARC are not memory safe. They are not. Not not not, and they don't even
try. :-)
That's fine. You can't have everything.
You're willing to dispense with memory safety?
No.
3. ARC objects require an embedded count. This means they cannot be
mixed with non-ARC objects. This is fundamentally DIFFERENT from how GC
behaves, and we cannot pretend or wish this away or add a compiler
switch to make it go away.
In nogc mode, everything is ARC so I'm not getting this.
Not even ARC languages try to make everything ARC - because it is
BLOATED and SLOW. Not C++, not ObjectiveC, not Rust.
Agreed.
D can have ref counted objects, but it will not work with a compiler
switch to switch them back and forth. They'll have to coexist peacefully
with GC objects.
We need to figure out a design. All I'm saying is we must not bring
prejudice to
the table. And a very basic point is: there will be a way to
COMPLETELY disable
the GC. That is a must.
It doesn't have to be disabled. Just don't call it. The GC is not a
bridge troll that is going to pop up and extract a toll even if you
aren't allocating with it.
Well obviously there's a hierarchy of desirability:
1. Using the GC inadvertently causes a compile-time error.
2. Using the GC inadvertently causes a link-time error.
3. Using the GC inadvertently causes a run-time error.
4. Using the GC inadvertently goes undetected.
I disagree that (4) is good for everyone.
Andrei
