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

"This is important because it limits what reference counted types." - I'm not sure what this means.

"The methods may or may not be final or inherited." - Should this be "final or virtual"?

"Any attributes are allowed on these methods." - I'm going to have to write a static analysis warning for marking these "const".

"Call is inserted only if the reference is not null" - Should this be "Call is executed only if the reference is not null"?

"</tt>opRelease</tt>" - Some markup escaped into the wild!

"The same is achievable with RCOs by means of @disable opAddRef();" - Suggestion: add some text stating that opRelease() must still be present and implemented.

"Attention must be paid to annotate with return all functions that return references to owned data" -> "Attention must be paid to annotate all functions that return references to owned data with `return`"

On 2/26/15 2:39 PM, Johannes Pfau wrote:
> Looks very nice, some things to refine:
>
> "Any attributes are allowed on these methods."
> * Should @safe and @trusted by disallowed as
>    "@safe code may not issue explicit calls to
>     opAddRef/opRelease"?
> * Probably also add a note here that the functions must be inverse and
>    a note that they should be nothrow and/or final for performance.

OK. I don't want to impose many limitations - let users explore possibilities. I added the recommendation.

> "This DIP proposes @safe reference counted class objects (including
> exceptions)"
> * Unfortunately the DIP doesn't talk about exceptions ;-) Will we
>    simply make Throwable a RCO?

Yes.

> "considers that opRelease is the inverse of opAddRef, and therefore is
> at liberty to elide pairs of calls"
> * Nice, but does that mean that reference-counted classes are now
>    superior to reference counted structs? It would be nice if the
>    compiler could also detect opRelease/opAddRef in structs. We could
>    still require user code to call these manually in postblits etc but
>    recognizing them would allow eliding pairs.

That's already taken care of - this(this) and ~this() are considered complementary.

> Also a more general question: What are the most important memory
> management strategies and which are handled by DIP25+DIP74?
> * GC
>    Of course supported
> * RC
>    Supported with DIP74. I think this could also be considered as ARC.
>    If not, what is missing from DIP74 compared to ARC?

Unless something major we didn't think of is found with DIP25 and DIP74, it's not impossible we found the perfect shade. Not only we'll offer automatic reference counting, but we'll allow people do define types that are usable in @safe code that do that.

> * Scoped (useful for stack objects)
>    Can 'return' be used to implement something which allocates a class
>    on the stack and prevents escaping references? I guess a Scope
>    struct allocating in place + a function returning a reference to the
>    class with 'return' (+ alias this) would work?

Yah, DIP74 can be directly used to make "scope w = new Widget;" work. But we'll address that in a distinct DIP in order to not bloat this one.

> * Owned
>    Supported by the member variables lifetime = parent lifetime rule?
> * Unique
>    ?
> * ?

Let's see.


Andrei

On 2/26/15 2:42 PM, Brian Schott 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
>
> "This is important because it limits what reference counted types." -
> I'm not sure what this means.
>
> "The methods may or may not be final or inherited." - Should this be
> "final or virtual"?
>
> "Any attributes are allowed on these methods." - I'm going to have to
> write a static analysis warning for marking these "const".
>
> "Call is inserted only if the reference is not null" - Should this be
> "Call is executed only if the reference is not null"?
>
> "</tt>opRelease</tt>" - Some markup escaped into the wild!
>
> "The same is achievable with RCOs by means of @disable opAddRef();" -
> Suggestion: add some text stating that opRelease() must still be present
> and implemented.
>
> "Attention must be paid to annotate with return all functions that
> return references to owned data" -> "Attention must be paid to annotate
> all functions that return references to owned data with `return`"

Excellent notes, of which two important ones. Addressed - reload http://wiki.dlang.org/DIP74 - thanks! -- Andrei

Am Thu, 26 Feb 2015 14:53:16 -0800
schrieb Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>:

> On 2/26/15 2:39 PM, Johannes Pfau wrote:
> > Looks very nice, some things to refine:
> >
> > "Any attributes are allowed on these methods."
> > * Should @safe and @trusted by disallowed as
> >    "@safe code may not issue explicit calls to
> >     opAddRef/opRelease"?
> > * Probably also add a note here that the functions must be inverse
> > and a note that they should be nothrow and/or final for performance.
> 
> OK. I don't want to impose many limitations - let users explore possibilities. I added the recommendation.

Leaving the implementation of opAddRef/opRelease to the user really opens some interesting possibilities. Wrapping manually reference-counted C libraries is a rather obvious one but there are probably more interesting cases.

Overall this proposal looks very nice :-)

Andrei Alexandrescu:

>The compiler detects automatically and treats specially all classes and interfaces that define the following two methods:<

Defining only one of those methods needs to give a compile-time error.


>This lowering assumes left-to-right evaluation of function parameters.<

Is this currently enforced in all D compilers?


>This DIP allows defining reference counted class objects that are usable in @safe code. However, it does not enforce safety.<

And do you plan to later design what's needed to enforce their safety?

Bye,
bearophile

On 2/26/15 3:19 PM, bearophile wrote:
> Andrei Alexandrescu:
>
>> The compiler detects automatically and treats specially all classes
>> and interfaces that define the following two methods:<
>
> Defining only one of those methods needs to give a compile-time error.

Well types that define empty() and front() but not popFront() are not in error, either.

>> This lowering assumes left-to-right evaluation of function parameters.<
>
> Is this currently enforced in all D compilers?

No, though there have been improvements. Brian submitted an(other) issue.

>> This DIP allows defining reference counted class objects that are
>> usable in @safe code. However, it does not enforce safety.<
>
> And do you plan to later design what's needed to enforce their safety?

Not at this time.


Andrei

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.

On 2/26/15 4:09 PM, 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.

No, see below how typechecking is more strict for RCOs. -- Andrei

On Friday, 27 February 2015 at 00:12:32 UTC, Andrei Alexandrescu wrote:
>> 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.
>
> No, see below how typechecking is more strict for RCOs. -- Andrei

That is simply a rhetoric way to not admit failure of DIP25 and DIP69.

On Fri, 27 Feb 2015 00:36:41 +0000, deadalnix wrote:

> On Friday, 27 February 2015 at 00:12:32 UTC, Andrei Alexandrescu wrote:
>>> 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.
>>
>> No, see below how typechecking is more strict for RCOs. -- Andrei
> 
> That is simply a rhetoric way to not admit failure of DIP25 and DIP69.

this stinks in the same way as DIP25 stinks. right here: "Attention must be paid to annotate all functions returning references to owned data with return." this single thing will bring enormous pile of bugs. i want to have $1 each time someone will be hit by the bug "oh, i forgot to put `return` there!", so i can drop my work and do nothing 'till the end of my life.