ooops, sorry, deadalnix, i was meant to post this as the answer to the OP post.

On Thu, 26 Feb 2015 13:50:55 -0800, Andrei Alexandrescu wrote:

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

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.

On Thu, Feb 26, 2015 at 01:50:55PM -0800, Andrei Alexandrescu via Digitalmars-d wrote:
> http://wiki.dlang.org/DIP74 got to reviewable form. Please destroy and discuss.
[...]

Under "Rules":
> The complexity of this code underlies the importance of making
                              ^^^^^^^^^
			      Should be "underlines"

> opAddRef and especially opRelease nothrow. In that case the
> scope(failure) statement may be elided.


Under "Rules":

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

This is unclear to me. What exactly is the semantics of "accomodate calls to Release"? And what is "Release"? Did you mean opRelease?

Also, the code example following is also unclear; since struct A has no RCO members that I can see, does that mean the calling sequences (labelled 1-9) apply to *all* structs now? Is Widget supposed to be RCO (this is not stated clearly)?

Similarly, in the next example about fun(exprA, exprB, exprC) it's not clear exactly which parameter is supposed to be RCO. I can guess, but it's better to be 100% unambiguous.


Then the rule that states that opAddRef and opRelease are not issued for 'this': is this safe from race conditions? E.g., if I'm inside a method and somebody outside calls opRelease and frees the object 'this' points to. Or are we assuming that RCOs must be thread-local? If so, this should be stated explicitly.


Under "Relinquishing an owned resource":

> The method is correctly not annotated with return because the slice it returns is not scoped by this. Note that if the implementer of Widget forgets the assignment _payload = null, user code may end up with a dangling reference.

So basically such a method cannot be marked @safe, right?


T

-- 
Only boring people get bored. -- JM

On 27/02/2015 10:50 a.m., Andrei Alexandrescu wrote:
> http://wiki.dlang.org/DIP74 got to reviewable form. Please destroy and
> discuss.
>
> Thanks,
>
> Andrei

Either I missed something or:

If I go new a type like:
Widget widget = new Widget();

This would still use the GC to allocate the memory + emplace it. Even if it contains the two special RC functions.

Also what about properties?
What if one of them may or may not be RC'd. Should there be a conditional call to the GC to add it to be scanned on assignment?

Anyway, I think it is mostly there.

On 2/26/15 5:28 PM, Rikki Cattermole wrote:
> On 27/02/2015 10:50 a.m., Andrei Alexandrescu wrote:
>> http://wiki.dlang.org/DIP74 got to reviewable form. Please destroy and
>> discuss.
>>
>> Thanks,
>>
>> Andrei
>
> Either I missed something or:
>
> If I go new a type like:
> Widget widget = new Widget();
>
> This would still use the GC to allocate the memory + emplace it. Even if
> it contains the two special RC functions.

Yah, DIP74 is intentionally very "policy up, implementation down". It completely leaves the allocation mechanism to user code. See e.g. this excerpt: "Usually such approaches also use private constructors and object factories to ensure the same allocation method is used during creation and destruction of the object."

> Also what about properties?
> What if one of them may or may not be RC'd. Should there be a
> conditional call to the GC to add it to be scanned on assignment?

I don't understand this. Members compose naturally.


Andrei

On Fri, Feb 27, 2015 at 12:59:38AM +0000, ketmar via Digitalmars-d wrote:
> On Thu, 26 Feb 2015 13:50:55 -0800, Andrei Alexandrescu wrote:
> 
> > http://wiki.dlang.org/DIP74 got to reviewable form. Please destroy and discuss.
> > 
> > Thanks,
> > 
> > Andrei
> 
> 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.
[...]

Wait, are you saying that forgetting the 'return' annotation will still compile without any warning?? Wow, that's ... not nice. :-(


T

-- 
Those who don't understand D are condemned to reinvent it, poorly. -- Daniel N

On Friday, 27 February 2015 at 00:10:00 UTC, deadalnix wrote:
> No problem, I'm gonna duplicate all my code and as will every single library writer out there.

Correct me if I'm wrong, but to me this presents itself as an alternative only for things that require deterministic ownership semantics(e.g, OpenGL resource wrapper)

I don't think this is a full ARC system intended to replace the GC that would require library authors to write two versions of their libraries.

But I could be entirely wrong.

On 2/26/15 3:12 PM, Johannes Pfau wrote:
> 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.

Yah, this should dovetail real nice with allocators too.

> Overall this proposal looks very nice :-)

Still looking for some sword to fall :o).


Andrei

On 2/26/15 5:37 PM, H. S. Teoh via Digitalmars-d wrote:
> On Fri, Feb 27, 2015 at 12:59:38AM +0000, ketmar via Digitalmars-d wrote:
>> On Thu, 26 Feb 2015 13:50:55 -0800, Andrei Alexandrescu wrote:
>>
>>> http://wiki.dlang.org/DIP74 got to reviewable form. Please destroy
>>> and discuss.
>>>
>>> Thanks,
>>>
>>> Andrei
>>
>> 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.
> [...]
>
> Wait, are you saying that forgetting the 'return' annotation will still
> compile without any warning?? Wow, that's ... not nice. :-(

The compiler will issue errors if returning ref to direct members. There won't be errors with returning ref to owned indirect members that the class deallocates manually. -- Andrei

On Thu, 26 Feb 2015 17:37:46 -0800, H. S. Teoh via Digitalmars-d wrote:

> On Fri, Feb 27, 2015 at 12:59:38AM +0000, ketmar via Digitalmars-d wrote:
>> On Thu, 26 Feb 2015 13:50:55 -0800, Andrei Alexandrescu wrote:
>> 
>> > http://wiki.dlang.org/DIP74 got to reviewable form. Please destroy and discuss.
>> > 
>> > Thanks,
>> > 
>> > Andrei
>> 
>> 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.
> [...]
> 
> Wait, are you saying that forgetting the 'return' annotation will still compile without any warning?? Wow, that's ... not nice. :-(

yep. this is the case for DIP25 too (see RCArray sample: it compiles perfectly fine without `return`).