Mac Apps That Use Garbage Collection Must Move to ARC

[Andrei Alexandrescu via Digitalmars-d]

On 2/22/15 9:53 PM, Manu via Digitalmars-d wrote:
> On 23 February 2015 at 14:11, Andrei Alexandrescu via Digitalmars-d
> <digitalmars-d at puremagic.com> wrote:
>> On 2/22/15 5:57 PM, Manu via Digitalmars-d wrote:
>>>
>>> I can easily visualise a way forward with RC.
>>
>>
>> Then do it. Frankly it seems to me you're doing anything you possibly can to
>> talk yourself out of doing work.
>
> Excellent technique to immediately invalidate everything someone says.
> Thanks for that.

It's not immediate - it's a pattern our dialog has followed for years. 
Essentially I haven't yet managed to communicate with you.

> You dismissed absolutely everything I said, and then imply that I have
> no right to comment unless I do it myself.
> It's got nothing to do with doing work. ARC (or something like it) is
> almost religiously opposed. We can't even have a reasonable
> conversation about it, or really explore it's implications before
> someone (that ideally know's what they're doing) thinks about writing
> code. There's no room for progress in this environment.

I think RC is an important tool on our panoply. More so than Walter. But 
I have to say you'd do good to understand his arguments better; it 
doesn't seem you do.

> What do you want me to do? I use manual RC throughout my code, but the
> experience in D today is identical to C++. I can confirm that it's
> equally terrible to any C++ implementation I've used. We have no tools
> to improve on it.

Surely you have long by now written something similar to std::shared_ptr 
by now. Please paste it somewhere and post a link to it, thanks. That 
would be a fantastic discussion starter.

> And whatever, if it's the same as C++, I can live with it. I've had
> that my whole career (although it's sad, because we could do much
> better).
> The problem, as always, is implicit allocations, and allocations from
> 3rd party libraries. While the default allocator remains incompatible
> with workloads I care about, that isolates us from virtually every
> library that's not explicitly written to care about my use cases.
> That's the situation in C++ forever. We're familiar with it, and it's
> shit. I have long hoped we would move beyond that situation in D
> (truly the #1 fantasy I had when I first dove in to D 6 years back),
> but it's a massive up-hill battle to even gain mindshare, regardless
> of actual implementation. There's no shared vision on this matter, the
> word is basically "GC is great, everyone loves it, use an RC lib".

It doesn't seem that way to me at all. Improving resource management is 
right there on the vision page for H1 2015. Right now people are busy 
fixing regressions for 2.067 (aiming for March 1; probably we won't make 
that deadline). In that context, posturing and stomping the ground that 
others work for you right now is in even more of a stark contrast.

> How long do we wait for someone to invent a fantastical GC that solves
> our problems and works in D?

This elucubration belongs only to you. Nobody's waiting on that. Pleas 
read http://wiki.dlang.org/Vision/2015H1 again.

> I think it's practically agreed that no
> known design can work, but nobody wants to bite the bullet and accept
> the fact.

I don't understand where this perception is coming from.

> We need to admit we have an impassable problem, and then maybe we can
> consider alternatives openly. Obviously, it would be disruptive, but
> it might actually work... which is better than where we seem to be
> heading (with a velocity of zero).

Please forgive people who are working on getting 2.067 out for not 
making things you need their top priority right now.

> The fact is, people who are capable of approaching this problem in
> terms of actual code will never even attempt it until there's
> resounding consensus that it's worth exploring.

Could you please let me know how we can rephrase this paragraph on 
http://wiki.dlang.org/Vision/2015H1:

=============
Memory Management

We aim to improve D's handling of memory. That includes improving the 
garbage collector itself and also making D eminently usable with limited 
or no use of tracing garbage collection. We aim to make the standard 
library usable in its entirety without a garbage collector. Safe code 
should not require the presence of a garbage collector.
=============

Could you please let me know exactly what parts you don't understand or 
agree with so we can change them. Thanks.


Andrei