On 22 February 2015 at 14:25, deadalnix via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Sunday, 22 February 2015 at 00:43:47 UTC, Manu wrote:
>>
>> I personally think ARC in D is the only way forwards. That is an unpopular opinion however... although I think I'm just being realistic ;)
>
>
> I've considered adding support for it in SDC in the future, but man, reading the ARC spec fells like a dive into insanity. I've rarely seen such an overcomplicated system.

But it IS a way forwards... can you suggest another way forwards using a sufficiently fancy GC? While there are no visible alternatives (as has been the case for as long as I've been here), I don't think complexity can be considered a road block. Would a theoretical advanced GC be any less complex?

What are the complexities? Can we design to address them elegantly?

On 22 February 2015 at 21:31, Jakob Ovrum via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Sunday, 22 February 2015 at 00:43:47 UTC, Manu wrote:
>>
>> D's GC is terrible, and after 6 years hanging out in this place, I have seen precisely zero development on the GC front.
>
>
> You must have missed RTInfo, Rainer's precise heap scanner and Sociomantic's concurrent GC.

Rasiner's GC was even slower (at the time it was presented), but it
offers the advantage that it doesn't leak like a seive. FWIW, I am in
favour of migrating to rainer's GC, but it doesn't really address any
problems.
Sociomantic's GC takes advantage of a particular OS, it's not portable.

On 2/22/15 3:39 AM, John Colvin wrote:
> On Sunday, 22 February 2015 at 00:43:47 UTC, Manu wrote:
>> On 22 February 2015 at 05:20, JN via Digitalmars-d
>> <digitalmars-d@puremagic.com> wrote:
>>> https://developer.apple.com/news/?id=02202015a
>>>
>>> Interesting...
>>>
>>> Apple is dropping GC in favor of automatic reference counting. What
>>> are the
>>> benefits of ARC over GC? Is it just about predictability of resource
>>> freeing? Would ARC make sense in D?
>>
>> D's GC is terrible, and after 6 years hanging out in this place, I
>> have seen precisely zero development on the GC front.
>
> There has been a flood of GC improvements in druntime from Martin Nowak
> and Rainer Schuetze over the last few months. Probably nothing that
> would satisfy your requirements, but it looks like some sizeable
> speedups nonetheless.

Martin, Rainer - it would be great if you could make public some measurements. -- Andrei

On 2/22/15 8:36 AM, Manu via Digitalmars-d wrote:
> On 22 February 2015 at 13:53, Daniel Murphy via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> "Manu via Digitalmars-d"  wrote in message
>> news:mailman.7037.1424565826.9932.digitalmars-d@puremagic.com...
>>
>>> I personally think ARC in D is the only way forwards. That is an
>>> unpopular opinion however... although I think I'm just being realistic
>>> ;)
>>
>>
>> A big part of why it's unpopular is that nobody, including you, wants to
>> implement it to see if it's viable.
>
> I have no idea where to start.

Simple approaches to reference counting are accessible to any software engineer. The right starting point is "I used reference counting in this project, and here are my findings".

A position such as the following makes the dialog very difficult:

1. One solution is deemed the only viable.

2. Details and difficulties are unknown to the proposer.

3. It must be implemented by others, not the proposer.

4. It must be part of the language; any experimentation outside the language is considered an unnecessary waste of time.


Andrei

On Sunday, 22 February 2015 at 16:37:15 UTC, Manu wrote:
> But it IS a way forwards... can you suggest another way forwards using
> a sufficiently fancy GC? While there are no visible alternatives (as
> has been the case for as long as I've been here), I don't think
> complexity can be considered a road block. Would a theoretical
> advanced GC be any less complex?
>
> What are the complexities? Can we design to address them elegantly?

It is overcomplex to accommodate the historical elements of ObjC.

On Sunday, 22 February 2015 at 16:15:44 UTC, Manu wrote:
> I can't overload on 'scope'. How can I create a scope
> constructor/destructor/postblit that doesn't perform the ref fiddling?
>
> On a tangent, can I pass rvalues to ref args now? That will massively
> sanitise linear algebra (matrix/vector) code big time!

The return ref thing is a feature that do not pay for itself.

On 2/22/2015 3:19 AM, Jacob Carlborg wrote:
> On 2015-02-22 03:23, Walter Bright wrote:
>
>> - RC has further performance and code bloat problems when used with
>> exception handling
>
> Exceptions in Objective-C are basically like Errors in D. Should not be caught
> and should terminate the applications.
>
> Swift doesn't event have exceptions.


And I suspect that ARC is why they don't have exceptions.

On 2/22/2015 8:15 AM, Manu via Digitalmars-d wrote:
> I can't overload on 'scope'. How can I create a scope
> constructor/destructor/postblit that doesn't perform the ref fiddling?

I don't understand what you're trying to do.

On 2/22/2015 8:36 AM, Manu via Digitalmars-d wrote:
> I have no idea where to start.

Start by making a ref counted type and see what the pain points are.

On 23 February 2015 at 06:49, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 2/22/2015 8:15 AM, Manu via Digitalmars-d wrote:
>>
>> I can't overload on 'scope'. How can I create a scope constructor/destructor/postblit that doesn't perform the ref fiddling?
>
>
> I don't understand what you're trying to do.

struct RCThing
{
  RefType *instance;

  this(this) { IncRef(instance); }
  ~this() { DecRef(instance); }

  this(this) scope {} // <- scope instances don't need ref fiddling
  ~this() scope {}
}

Or various permutations along those lines.
Ie, library types may eliminate their ref fiddling when they are scope.