Mac Apps That Use Garbage Collection Must Move to ARC

[Walter Bright via Digitalmars-d]

On 2/25/2015 7:12 AM, Manu via Digitalmars-d wrote:
> It does annoy me that I can't comment on the exceptions case,

That problem is easily correctable. But if you aren't interested in doing the 
homework, you're stuck with accepting what I say about it :-)


> That said, I'd still be surprised if it was a terminal argument
> though. Is it really a hard impasse? Or is it just a big/awkward
> burden on the exceptional path? Surely the performance of the unwind
> path is irrelevant? Does it bleed into the normal execution path?

I've answered these questions to you already. I've also quoted the ObjectiveC 
compiler document saying the same thing. At some point you're going to either 
have to spend some time investigating it yourself or cede the point.


> I recognise there is some GC action recently, but I haven't seen any
> activity that changes the fundamental problems?

DIP25.


> COM is also an excellent candidate for consideration. If COM works
> well, then I imagine anything should work.
> Microsoft's latest C++ presents a model for this that I'm generally
> happy with; distinct RC pointer type. We could do better by having
> implicit cast to scope(T*) (aka, borrowing) which C++ can't express;
> scope(T*) would be to T^ and T* like const(T*) is to T* and
> immutable(T*).

Microsoft's Managed C++ had two pointer types, and it went over like a lead 
zeppelin.


> There have been lots of people come in here and say "I won't use D
> because GC",

None of those people will be satisfied with improvements to the GC.


> This is a bit of a red herring, the roadmap has no mention of ARC, or
> practical substitution for the GC. This discussion was originally
> about ARC over the GC, specifically.

See the refcounted array thread.


> I hope I'm completely wrong. Really!

I suspect you are hoping for a magic switch:

    dmd foo.d -arc

and voila! Everything will be reference counted rather than GC'd.

This is never going to happen with D. I don't see a path to it that does not 
involve crippling problems and compromises.

However, D will become usable with minimal or no use of the GC, by using 
components that are allocation agnostic, and selection of types that are RC'd. I 
suspect most programs will wind up using combinations of GC and RC.


> I wouldn't complain if efficient RC was on the roadmap, but I agree
> it's outside the scope for the immediate future.

Refcounted array thread.


> As I said above, and many many times in the past, I see the @nogc
> effort leading to a place where libraries are firmly divided between 2
> worlds. My criticisms of that kind have never been directly addressed.

I don't buy that. The canonical example is std.algorithm, which is highly useful 
components that are allocation strategy agnostic. I have since added 
splitterLines() which replaces the old GC splitLines() function with a component 
that is agnostic. This is an example of the way forward.