On 9/19/2014 8:13 PM, Daniel N wrote:
> What does the GC bring to exceptions that makes it sufficiently invaluable to
> warrant two parallel implementations? It can't be about performance, since
> _thrown_ exceptions are already in the slow path... Backwards compatibility?

Backwards compatibility.

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.

On Saturday, 20 September 2014 at 03:25:39 UTC, Walter Bright wrote:
> On 9/19/2014 8:13 PM, Daniel N wrote:
>> What does the GC bring to exceptions that makes it sufficiently invaluable to
>> warrant two parallel implementations? It can't be about performance, since
>> _thrown_ exceptions are already in the slow path... Backwards compatibility?
>
> Backwards compatibility.

Thanks!

As much as I applaud our efforts for Backwards compatibility, it only affects code which already has been written, whereas a switch would affect "all" code that will be written, imho the burden both on library and app devs would be less if we simply redefined Throwable.

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

On 9/19/14, 7:26 PM, 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.

I don't think there will be division, and I don't think the parts will fail. I see it as enrichment.

We've said for years that D is usable without a GC. The time has come to make that into reality. To the extent it's automatic, we'll make it automatic. To the extent we'll require adjustment in use, we'll ask users to adjust use. The worst thing about that is to enter the design with a prejudice tied to our ankles.

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


Andrei

On 9/19/14, 8:13 PM, Daniel N wrote:
> On Saturday, 20 September 2014 at 02:26:49 UTC, Walter Bright wrote:
>> 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 basically agree with Walter on this one, no switch please, it's
> maintenance nightmare for library devs.

Why is it a maintenance nightmare?

> My proposal would be to permanently use ARC for Throwable, no flags.

How about other objects? Throwable is but the first step, and a good one to inform larger designs. We can't force RC on all objects on all applications.

> What does the GC bring to exceptions that makes it sufficiently
> invaluable to warrant two parallel implementations? It can't be about
> performance, since _thrown_ exceptions are already in the slow path...
> Backwards compatibility?

Conversion from Throwable to Object.


Andrei

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

On 9/19/14, 8:45 PM, Daniel N wrote:
> As much as I applaud our efforts for Backwards compatibility, it only
> affects code which already has been written, whereas a switch would
> affect "all" code that will be written, imho the burden both on library
> and app devs would be less if we simply redefined Throwable.

We need -nogc in the same way we need -m32 and -m64. -- Andrei

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.

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

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.


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

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.

On Fri, 19 Sep 2014 21:53:32 -0700
Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com>
wrote:

> Changing nothing is not an option. Ideas? -- Andrei
let compiler do it's ARC magic on Throwable and allow programmer to plug in his own allocator. and drop out GC mechanics for Throwables entirely (except scanning Throwable instance for GC-managed pointers).