On Thu, Feb 26, 2015 at 06:39:12PM -0800, Andrei Alexandrescu via Digitalmars-d wrote:
> On 2/26/15 6:21 PM, H. S. Teoh via Digitalmars-d wrote:
> >On Thu, Feb 26, 2015 at 06:06:04PM -0800, Andrei Alexandrescu via Digitalmars-d wrote:
> >>On 2/26/15 5:59 PM, H. S. Teoh via Digitalmars-d wrote:
> >>>On Thu, Feb 26, 2015 at 05:44:36PM -0800, Andrei Alexandrescu via Digitalmars-d wrote: [...]
> >>>>An interesting option to explore in the future would be rigging druntime to add opAddRef and opRelease to Object.
> >>>[...]
> >>>
> >>>How would that work? Doesn't that immediately subject *all* classes to the restrictions set forth in DIP74?
> >>
> >>It does - but that might be fine with some applications. -- Andrei
> >
> >But putting it into druntime imposes it on *all* applications, because either opAddRef/opRelease are declared in Object, or they are not, and this decision is made long before the user writes his application.
> 
> That's why I used "rigging" - meaning "equip for special purpose". "Hacking" is clearer. Someone may decide to just add opAddRef/opRelease to Object for a system or application. Or make the addition subject to a versioning flag (and therefore have two druntime builds available).
[...]

Ahhh, I see what you mean now. That's an interesting idea... I suppose people like Manu could like to do something like this to get ARC by default, for example.


T

-- 
Do not reason with the unreasonable; you lose by definition.

On 2/26/2015 5:37 PM, H. S. Teoh via Digitalmars-d wrote:
> Wait, are you saying that forgetting the 'return' annotation will still
> compile without any warning?? Wow, that's ... not nice. :-(

Indeed, and the compiler will error out if you try that:

---
struct S {
    int x;
}

ref int foo(ref S s) {
    return s.x;
}
---

dmd -c foo -dip25
foo.d(7): Error: escaping reference to local ref variable s

There'd be no point to DIP25 if it didn't.

On Friday, 27 February 2015 at 00:10:00 UTC, deadalnix wrote:
> On Thursday, 26 February 2015 at 21:50:56 UTC, Andrei Alexandrescu wrote:
>> http://wiki.dlang.org/DIP74 got to reviewable form. Please destroy and discuss.
>>
>> Thanks,
>>
>> Andrei
>
> "The compiler detects automatically and treats specially all classes and interfaces that define the following two methods:"
>
> Well, RefCounted could use compile time reflexion to do so. Even better, we could define a lvalue property for RefCounted to use a counter so we can do intrusive counting in both classes and structs.
>
> "@safe code may not issue explicit calls to opAddRef/opRelease. "
>
> I guess we could simply make them @system .
>
> " RCOs objects are subject to additional limitations compared to their GC counterparts:
>
> No conversion to Object or interfaces that are not reference counted "
>
> No problem, I'm gonna duplicate all my code and as will every single library writer out there.
>
> Missing:
>
> All write of RCO reference to statics must be atomic and ordered as long as the language can't enforce thread locality (at least in @safe code).
>
> Generally:
> This DIP works around (announced) limitations of DIP25. As escape can only be checked properly for type with no indirections, and only solve the problem for classes/interfaces. Other type with indirection remains an unsolved problem.
>
> If I were in charge, that would be a clear no, and the sign that DIP25 approach needs to be reworked, as wack-a-mole is not a good way to handle design.

We all pray you become less of a gaping asshole before youre in
charge of anything.

On 2015-02-26 22:50, Andrei Alexandrescu wrote:
> http://wiki.dlang.org/DIP74 got to reviewable form. Please destroy and
> discuss.

To me this looks like ARC (Automated Reference Counting). I know that Walter has several complains about ARC, like he wrote in another thread [1]:

"RC has further performance and code bloat problems when used with exception handling"

Is that dealt with or is it something one just have to accepted when using reference counting?

[1] http://forum.dlang.org/post/mcbejn$2tao$1@digitalmars.com

-- 
/Jacob Carlborg

On Thursday, 26 February 2015 at 22:04:09 UTC, Andrei Alexandrescu wrote:
> On 2/26/15 2:03 PM, Brian Schott wrote:
>>
>> One of the first things that stood out to me is that "add ref" is two
>> words and "release" is one. For the sake of symmetry, how about these:
>> *  opIncRef, opDecRef
>> *  opAcquire, opRelease
>
> All - please PLEASE do not derail this into yet another debate about which names are best. -- Andrei

Using protocols rather than enforcing a particular implementation is nice, but D needs to stop reinventing terminology and syntax matters.


Acquire/Release:

https://msdn.microsoft.com/en-us/library/windows/hardware/ff540496%28v=vs.85%29.aspx


Retain/Release:

https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/MemoryMgmt.html


AutoRelease pools / Drain:

https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSAutoreleasePool_Class/index.html#//apple_ref/occ/instm/NSAutoreleasePool/drain


Antonyms for "release":

http://www.merriam-webster.com/thesaurus/release[verb]

On Thursday, 26 February 2015 at 22:02:51 UTC, Andrei Alexandrescu wrote:
>> So is the end game of dip25 and dip74 to not have to wrap types you
>> intend to manage with RC like C++ but just design the classes/structs
>> themselves around being RCed from the start?
>
> That is correct. Well as shown there are ways to design classes that work both with RC and GC. -- Andrei

If a class is meant to be refcounted at compile time, what's a difference from
alias MyClass = RefCounted!MyClassImpl;
// use MyClass instead
except for it introduces an additional check for null and a branch?

On Friday, 27 February 2015 at 08:26:14 UTC, Ola Fosheim Grøstad wrote:
> Acquire/Release:
>
> https://msdn.microsoft.com/en-us/library/windows/hardware/ff540496%28v=vs.85%29.aspx

That's about cache coherency, reference counting is only an illustration. And this is about reference counting: https://msdn.microsoft.com/en-us/library/windows/desktop/ms680509.aspx

On Friday, 27 February 2015 at 08:56:49 UTC, Kagamin wrote:
> On Friday, 27 February 2015 at 08:26:14 UTC, Ola Fosheim Grøstad wrote:
>> Acquire/Release:
>>
>> https://msdn.microsoft.com/en-us/library/windows/hardware/ff540496%28v=vs.85%29.aspx
>
> That's about cache coherency, reference counting is only an illustration. And this is about reference counting: https://msdn.microsoft.com/en-us/library/windows/desktop/ms680509.aspx

Yeah, and that page documents why the Bill Gatish Microsoft sucks. They used to invent their own incoherent  standards/terminology...

Andrei Alexandrescu wrote:

> http://wiki.dlang.org/DIP74 got to reviewable form. Please destroy and discuss.
> 
> Thanks,
> 
> Andrei

Trivial typos:

struct, class, and closure types that have RCO members accommodate calls to Release during their destruction. s/Release/opRelease/

Explicit casting to of from void* does not entail a call to opAddRef. s/of/or/

also: s/opReleasecalls/opRelease calls/

The examples in "Defining a reference counted object with deallocation", and "defining a type that owns resources" both define '_refs', and manipulate 'refs'.


This is probably a really stupid question, but how does the 'new' work for an RCO. I assume it uses the GC memory allocation system, but must mark it as 'not for collection' (or similar), for the GC.free() call to work (as used in the examples).

Probably another silly question: How would the examples work with
const/immutable (using examples in howtos)?
e.g. const Widget a = new Widget;
     auto b = a;	<-- mutable method Widget.opAddRef is not callable
using a const object

On Thursday, 26 February 2015 at 21:50:56 UTC, Andrei Alexandrescu wrote:
> http://wiki.dlang.org/DIP74 got to reviewable form. Please destroy and discuss.

Destroy:

The scheme is too simplistic.

You need to add "policy" as a template parameter to retain/release so that you can support different ownership schemes with strong typing (compile time).

You also need a policy-link between the receiver and the object.

The DIP needs to prove that the protocol can be used to efficiently implement the following in various configurations:

- weak-references with zeroing

- auto release pools

- unique ownership

- optional locking and transfer between threads

- wrapping of foreign objects that have their own RC scheme