On Sunday, 21 September 2014 at 09:07:58 UTC, Johannes Pfau wrote:
> 7) The GC needs to be implemented in D, in the druntime.

Eh, it is easy to write a stub function that just calls malloc. The main problem with that is what Andrei said: most code won't call free since it doesn't have to, so it would leak in those situations. But if you're writing code for this situation, it is easy enough to call free; you don't *have* to, but you *can* (unless it is @safe code, then you can't).

On 9/21/14, 1:51 AM, Jacob Carlborg wrote:
> On 2014-09-20 18:56, Andrei Alexandrescu wrote:
>
>> Please don't take me in a court of law. But yes, I am talking about the
>> compiler inserting calls to increment and decrement reference counts. --
>> Andrei
>
> We do need to know what you're proposal is for.

The title is an incomplete summary. Exceptions would be transparently reference counted. I.e. no changes in user code.

A little more detail on a design Walter has put together: define a new root class RCObject. Neither Object nor RCObject inherit each other. All classes that inherit RCObject are detected by the compiler as reference counted.

(For practical reasons, RCObject will implement IUnknown. There are a few random consequences of that (meaningless method QueryInterface, no class info, no monitor, COM-compatible layout) but IUnknown already has AddRef and Release and the compiler already recognizes IUnknown as a special case. Hooking RCObject there will leave us with two roots instead of adding a third one.)

Throwable will inherit RCObject. The compiler inserts AddRef and Release whenever copying RCObject (and derivatives) references around, of course following a null check.

The caveats discussed previously in http://goo.gl/Xl5U3z do apply.


Andrei

On Saturday, 20 September 2014 at 16:50:08 UTC, Andrei Alexandrescu wrote:
> On 9/20/14, 7:33 AM, Dicebot wrote:
>> On Saturday, 20 September 2014 at 14:31:36 UTC, Adam D. Ruppe wrote:
>>> How often do you store an exception reference anyway that escapes a
>>> catch block? I think all this talk is overkill to solve a non-problem
>>> in 99% of practice.
>>
>> Pretty much any time you do fibers + async I/O : to emulate blocking API
>> one needs to catch and store exceptions from I/O routines so that later
>> those can be re-thrown from resumed fiber context.
>
> Interesting. Are those stored as Object or Throwable/Exception? -- Andrei

I'd expect Throwable. Erasing it to Object smells like a trouble for no good. Don't know how Sonke has implemented in vibe.d though.

On Sunday, 21 September 2014 at 15:03:09 UTC, Andrei Alexandrescu wrote:
> On 9/21/14, 1:51 AM, Jacob Carlborg wrote:
>> On 2014-09-20 18:56, Andrei Alexandrescu wrote:
>>
>>> Please don't take me in a court of law. But yes, I am talking about the
>>> compiler inserting calls to increment and decrement reference counts. --
>>> Andrei
>>
>> We do need to know what you're proposal is for.
>
> The title is an incomplete summary. Exceptions would be transparently reference counted. I.e. no changes in user code.
>
> A little more detail on a design Walter has put together: define a new root class RCObject. Neither Object nor RCObject inherit each other. All classes that inherit RCObject are detected by the compiler as reference counted.
>
> (For practical reasons, RCObject will implement IUnknown. There are a few random consequences of that (meaningless method QueryInterface, no class info, no monitor, COM-compatible layout) but IUnknown already has AddRef and Release and the compiler already recognizes IUnknown as a special case. Hooking RCObject there will leave us with two roots instead of adding a third one.)
>
> Throwable will inherit RCObject. The compiler inserts AddRef and Release whenever copying RCObject (and derivatives) references around, of course following a null check.
>
> The caveats discussed previously in http://goo.gl/Xl5U3z do apply.
>
>
> Andrei

This makes much more sense to me than initial proposal. I may even be brave enough to say that I like it :)

On 9/21/14, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> (For practical reasons, RCObject will implement IUnknown.

IUnknown has this issue btw: https://issues.dlang.org/show_bug.cgi?id=12607

On 9/21/14, 9:42 AM, Andrej Mitrovic via Digitalmars-d wrote:
> On 9/21/14, Andrei Alexandrescu via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> (For practical reasons, RCObject will implement IUnknown.
>
> IUnknown has this issue btw:
> https://issues.dlang.org/show_bug.cgi?id=12607

Thanks, good to know. IMHO having RCObject inherit IUnknown is more of a distraction than a benefit, but I'll let Walter be the judge of that. -- Andrei

On Sunday, 21 September 2014 at 18:10:53 UTC, Andrei Alexandrescu wrote:
> Thanks, good to know. IMHO having RCObject inherit IUnknown is more of a distraction than a benefit, but I'll let Walter be the judge of that. -- Andrei

Actually, I think it is a good idea to do the refcounting thing on COM objects anyway. I've used wrapper structs for that in the past, but if you don't do that right you can escape a reference which is freed, so putting it right on the object is kinda useful.

Of course, IUnknown AND RCObject could be refcounted roots.

21-Sep-2014 19:03, Andrei Alexandrescu пишет:
> On 9/21/14, 1:51 AM, Jacob Carlborg wrote:
>> On 2014-09-20 18:56, Andrei Alexandrescu wrote:
>>
>>> Please don't take me in a court of law. But yes, I am talking about the
>>> compiler inserting calls to increment and decrement reference counts. --
>>> Andrei
>>
>> We do need to know what you're proposal is for.
>
[snip]
>
> (For practical reasons, RCObject will implement IUnknown. There are a
> few random consequences of that (meaningless method QueryInterface, no
> class info, no monitor, COM-compatible layout) but IUnknown already has
> AddRef and Release and the compiler already recognizes IUnknown as a
> special case. Hooking RCObject there will leave us with two roots
> instead of adding a third one.)
>

This is actually a nice choice since COM would then (eventually) benefit from whatever automatic ref-counting we embed into the compiler.
This is exactly what Visual C++ does now for new style COM object (inherited from IInspectable).

-- 
Dmitry Olshansky

BTW hmmm what about this:

interface Foo { }

class Bar : Foo, RCObject {}

class Pwned : Foo {}

void main() {
   Foo bar = new Bar();
   /* where is bar.Release() called? */
   Foo pwned = new Pwned();
   /* better hope pwned.Release() isn't called cuz that's impossible */
}


I *believe* IUnknown interfaces are special and a separate category from regular D interfaces, so this would be statically disallowed.

But with the RCObject, we need to be careful about implicit casting to interfaces transparently killing memory safety.

of course then we might be weakening their usefulness. gah we just need scope references, then we can pass the interface with confidence that it won't be escaped. yeah yeah i know i sound like a broken record.

On 9/21/14, 11:20 AM, Adam D. Ruppe wrote:
> BTW hmmm what about this:
>
> interface Foo { }
>
> class Bar : Foo, RCObject {}
>
> class Pwned : Foo {}
>
> void main() {
>     Foo bar = new Bar();
>     /* where is bar.Release() called? */
>     Foo pwned = new Pwned();
>     /* better hope pwned.Release() isn't called cuz that's impossible */
> }
>
>
> I *believe* IUnknown interfaces are special and a separate category from
> regular D interfaces, so this would be statically disallowed.
>
> But with the RCObject, we need to be careful about implicit casting to
> interfaces transparently killing memory safety.

Good point.

> of course then we might be weakening their usefulness. gah we just need
> scope references, then we can pass the interface with confidence that it
> won't be escaped. yeah yeah i know i sound like a broken record.

I don't think scope references are workable. I'll explain why in a latter post.


Andrei