RFC: reference counted Throwable

[Andrei Alexandrescu via Digitalmars-d]

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