On Saturday, 20 September 2014 at 05:24:11 UTC, Walter Bright wrote:
> 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.

If you don't expose the refcount, write libraries as if you have only RC, and don't expose destructors then you probably can. Just turn inc/dec into dummies.

Consider:

https://github.com/D-Programming-Language/phobos/blob/master/std/c/windows/com.d#L218

This is D's support for COM objects. They have AddRef() and Release(), i.e. they are reference counted. They do not inherit from Object. The refcounting is currently manual.

D could allow an additional root (not a replacement) for thrown Exceptions. This root would be based on ComObject.

As a bonus, COM objects were designed for C++, and C++ implements them well, i.e. they would be a compatible object structure.

catch statements could be changed to catch ComThrowable, which would not catch Throwables, and catches for Throwables would not catch ComThrowables.

On 9/19/14, 10:24 PM, Walter Bright wrote:
> On 9/19/2014 9:47 PM, Andrei Alexandrescu wrote:
>>> We've had this discussion numerous times before - "throw the magic
>>> compiler switch" and D becomes an ARC system and everything is
>>> wonderful. It cannot work. ARC and GC are not equivalent.
>>
>> I think past discussions have been inconclusive at best and must be
>> reopened.
>
> For starters,
>
> 1. ARC is slow and generates bloated code.

Agreed. It has the cost distributed a different way.

> 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.

> 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.

> None of these points were addressed in previous discussions beyond the
> supposition of some nonexistent compiler technology that would make them
> go away.

That was indeed a crappy argument, and not advanced by me. I'm not advocating for that.

> 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.


Andrei

On 9/19/2014 10:32 PM, Ola Fosheim Grostad wrote:
> On Saturday, 20 September 2014 at 05:24:11 UTC, Walter Bright wrote:
>> 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.
>
> If you don't expose the refcount, write libraries as if you have only RC, and
> don't expose destructors then you probably can. Just turn inc/dec into dummies.

This doesn't address any of the 3 concerns.

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?


>> 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.


>> 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.

Am 20.09.2014 06:43, schrieb Andrei Alexandrescu:
> On 9/19/14, 7:20 PM, Walter Bright wrote:
>> On 9/19/2014 6:48 PM, Andrei Alexandrescu wrote:
>>> On 9/19/14, 6:18 PM, Walter Bright wrote:
>>>> Having a compiler switch to change the behavior of every module in
>>>> incompatible ways would be a disastrous balkanization. It has to be
>>>> done
>>>> in such a way that the ARC and the existing exceptions can coexist.
>>>
>>> Could you please elaborate why the disaster? -- Andrei
>>>
>>
>> 1. Every library for D will have to come in two versions. One which
>> works, and the other is likely untested. This will divide the D
>> community in half.
>
> I understand where you're coming from. And you're right that we're
> looking at an important change - as big as -m64 vs. -m32 or porting to a
> new platform. It's big. But it's needed, soon. And it would be, it seems
> to me, a mistake to approach this big change as a small change that we
> can sneak in.
>
> This judgment - that RC vs. GC would balkanize the community - has
> become a prejudice that is worth revisiting. Just trotting it out again
> won't do.
>
>> 2. RC and GC engender different styles of programming. The idea that one
>> can successfully switch between them with merely a compiler switch is a
>> fantasy. You cannot write non-trivial programs that function well and
>> pay no attention to how memory management is done.
>
> I think we're at a point where we owe it to ourselves to consider
> realizing the fantasy.
>
>
> Andrei
>

This is one of the reasons why the Objective-C GC failed.

Mixing Frameworks compiled with both modes never worked properly.

--
Paulo

On Saturday, 20 September 2014 at 06:01:19 UTC, Walter Bright wrote:
> This doesn't address any of the 3 concerns.

1. RC efficiency is architecture dependent. E.g. TSX is coming even if there is a bug in lower end CPUs. Suggest making performance oriented prototypes on different architectures before concluding.

2. As long as you have a RC pointer to an obj on the stack you can switch to regular references. No magic involved for the easy case, just semantic analysis.

3. True, but you can keep the refcount at a negative offset for new-based allocations. Besides it only affects those who do @nogc and they should know what they are doing.

On Saturday, 20 September 2014 at 02:26:49 UTC, Walter Bright wrote:
> On 9/19/2014 7:04 PM, Vladimir Panteleev wrote:
>> On Saturday, 20 September 2014 at 01:19:05 UTC, Walter Bright wrote:
>>> Having a compiler switch to change the behavior of every module in
>>> incompatible ways would be a disastrous balkanization.
>>
>> Don't -version, -debug etc. have this problem anyway?
>
> I submit that it is a poor practice to write code that way.
>
>
>> Anyway, if you change the name mangling, then you'll get link errors instead of
>> mysterious crashes.
>>
>>> It has to be done in such a way that the ARC and the existing exceptions can
>>> coexist.
>>
>> How?
>
> Good question. It's a challenge. But it has to be done, or D will divide in half and both halves will fail.
>
>
> We've had this discussion numerous times before - "throw the magic compiler switch" and D becomes an ARC system and everything is wonderful. It cannot work. ARC and GC are not equivalent.

I am fully with Walter here. Only way to do it in acceptable way is to make both  reference counted exceptions and current ones co-exist. Anything else means that we will need to distribute 4 builds of Phobos - debug-nogc, debug-gc, release-nogc, release-gc. Guess you can smell exponential explosion here as well as I do.

On Saturday, 20 September 2014 at 04:53:32 UTC, Andrei Alexandrescu wrote:
> On 9/19/14, 8:30 PM, ketmar via Digitalmars-d wrote:
>> On Fri, 19 Sep 2014 08:32:38 -0700
>> Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com>
>> wrote:
>>
>>> First, there must be some compiler flag -nogc or something, which
>> please, no compiler switches! it's partly ok for "-release", it's not
>> very good for "-version" and it's awful to add another one which
>> completely alters the way something works. as much as i want to make
>> throwables nogc, it's better to change nothing than to add such switch.
>
> Changing nothing is not an option. Ideas? -- Andrei

I have been thinking about something like `ARC` interface and `ARCException : Throwable, ARC` with all the automatic ref inc/dec calls you have mentioned added for any class that implements `ARC` interface.

On Saturday, 20 September 2014 at 07:29:52 UTC, Dicebot wrote:
> I have been thinking about something like `ARC` interface and `ARCException : Throwable, ARC` with all the automatic ref inc/dec calls you have mentioned added for any class that implements `ARC` interface.

..and yes, I'd expect it to be the default one used by Phobos (possibly with some backing pool allocator). It isn't critical for GC-enabled applications to use GC-based exceptions but contrary is true.