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

LGTM, it is great to see something done for deterministic class destruction.

It's unclear to me if an RCO object is a subtype of the corresponding class or the reverse or none.

On 2/27/15 2:03 PM, ted wrote:
> I'm still a bit confused here: the examples in DIP74 showed the freeing of
> memory via 'GC.free(cast(void*) this);' - so I had assumed that
> 'Widget a = new Widget' would be the way it was created? (and that
> automatically uses GC - or is this what I am missing?)

The GC allows both manual freeing and via tracing. So after allocating with new, a user may either leave it to the GC or call the destructor followed by GC.free.

> I can see how a system that used (for example) malloc/calloc/free would
> work, I'm just querying the consistency of the examples within DIP74?

GC.malloc/GC.free and malloc/free should both work.


Adnrei

From the perspective of someone mostly indifferent to the support for it:

Why does DIP74 require the references to be counted on assignment? Shouldn't it be defined such that reference counting operations only need to occur when an unbalanced or escapable reference is created? This would eliminate a large number of the required references. As long as the reference count of an object is the same entering a function as when it leaves the function, there's no need to do a bunch of twiddling in the middle.

It also appears to me that the opAddRef in the examples is simpler than it should be. I believe it should be doing an `assert(_refs)` first, to ensure a valid state entering into the function.

Lastly, I believe it should be opReleaseRef rather than opRelease, simply to be explicit on what is being released.

On Fri, 27 Feb 2015 20:13:31 +0000, weaselcat wrote:

> Are op* considered reserved member names?

no. that's just the "we can break your code, and you can't break ours!" it's funny how the argument "we will not break user's code" pops up even for breaking invalid code, but completely ignored for perfectly valid code not forbidden by the specs.

On Saturday, 28 February 2015 at 03:49:04 UTC, ketmar wrote:
> On Fri, 27 Feb 2015 20:13:31 +0000, weaselcat wrote:
>
>> Are op* considered reserved member names?
>
> no. that's just the "we can break your code, and you can't break ours!"
> it's funny how the argument "we will not break user's code" pops up even
> for breaking invalid code, but completely ignored for perfectly valid
> code not forbidden by the specs.

I think this is justified to break the code here, but I share the irritation in front of the inconsistency.

On Saturday, 28 February 2015 at 05:57:19 UTC, deadalnix wrote:
> On Saturday, 28 February 2015 at 03:49:04 UTC, ketmar wrote:
>> On Fri, 27 Feb 2015 20:13:31 +0000, weaselcat wrote:
>>
>>> Are op* considered reserved member names?
>>
>> no. that's just the "we can break your code, and you can't break ours!"
>> it's funny how the argument "we will not break user's code" pops up even
>> for breaking invalid code, but completely ignored for perfectly valid
>> code not forbidden by the specs.
>
> I think this is justified to break the code here, but I share the irritation in front of the inconsistency.

I agree, as, well, this is starting to look pretty grotesque...

The druntime/phobos 2.067 are breaking every piece of software out there that relies on core.sync or concurrency.scheduler, vibe and tango included.

I admit that breakages coming from phobos' changes are pretty different from a breakages coming from compiler changes, but we are talking about the runtime library also.

Oh well, who cares: my backlog of D code tasks at work is too long to start complaining... let's go back to the code...

---
Paolo

"Paolo Invernizzi"  wrote in message news:wkcsqtzjqybortkabpkv@forum.dlang.org...

> The druntime/phobos 2.067 are breaking every piece of software out there that relies on core.sync or concurrency.scheduler, vibe and tango included.

This is an exaggeration... 

On Saturday, 28 February 2015 at 10:30:55 UTC, Daniel Murphy wrote:
> "Paolo Invernizzi"  wrote in message news:wkcsqtzjqybortkabpkv@forum.dlang.org...
>
>> The druntime/phobos 2.067 are breaking every piece of software out there that relies on core.sync or concurrency.scheduler, vibe and tango included.
>
> This is an exaggeration...

This is reality: both actual version of vibe.d and tango can't be compiled with 2.067, and it's a reality that this put some real work to do on the shoulders of the maintainers.

---
Paolo

"Paolo Invernizzi"  wrote in message news:avsvjanhckbcjttaolwc@forum.dlang.org...

>> The druntime/phobos 2.067 are breaking every piece of software out there that relies on core.sync or concurrency.scheduler,

> This is reality: both actual version of vibe.d and tango can't be compiled with 2.067, and it's a reality that this put some real work to do on the shoulders of the maintainers.

Every project that overrides those methods is far from every project that relies on core.sync or core.scheduler. 

On Saturday, 28 February 2015 at 11:03:14 UTC, Daniel Murphy wrote:
> "Paolo Invernizzi"  wrote in message news:avsvjanhckbcjttaolwc@forum.dlang.org...
>
>>> The druntime/phobos 2.067 are breaking every piece of software out there that relies on core.sync or concurrency.scheduler,
>
>> This is reality: both actual version of vibe.d and tango can't be compiled with 2.067, and it's a reality that this put some real work to do on the shoulders of the maintainers.
>
> Every project that overrides those methods is far from every project that relies on core.sync or core.scheduler.

I agree with you in that.

/P