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

Thanks,

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


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?

On 2/26/15 2:01 PM, weaselcat 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
>
>
> 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

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

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

The DIP states that "Any attributes are allowed on these methods.", but later states "The complexity of this code underlies the importance of making opAddRef and especially opRelease nothrow". Should the DIP require that these two functions be marked nothrow?

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

On 2/26/15 2:03 PM, Brian Schott wrote:
> The DIP states that "Any attributes are allowed on these methods.", but
> later states "The complexity of this code underlies the importance of
> making opAddRef and especially opRelease nothrow". Should the DIP
> require that these two functions be marked nothrow?

It's a liberty still left to user code. -- 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

"This lowering assumes left-to-right evaluation of function parameters." -DIP 74

"The following binary expressions are evaluated in an implementation-defined order: AssignExpression, function arguments" - http://dlang.org/expression.html

On 2/26/15 2:17 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 lowering assumes left-to-right evaluation of function parameters."
> -DIP 74
>
> "The following binary expressions are evaluated in an
> implementation-defined order: AssignExpression, function arguments" -
> http://dlang.org/expression.html

Yah, Walter mentioned these. We need to fix them. -- Andrei

On Thursday, 26 February 2015 at 22:22:53 UTC, Andrei Alexandrescu wrote:
> Yah, Walter mentioned these. We need to fix them. -- Andrei

https://issues.dlang.org/show_bug.cgi?id=14228

Am Thu, 26 Feb 2015 13:50:55 -0800
schrieb Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>:

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

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.


"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?


"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.



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?
* 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?
* Owned
  Supported by the member variables lifetime = parent lifetime rule?
* Unique
  ?
* ?