On 4/30/14, 1:46 PM, deadalnix wrote:
> On Wednesday, 30 April 2014 at 20:21:33 UTC, Andrei Alexandrescu wrote:
>> That means classes that need cleanup (either directly or by having
>> fields that are structs with destructors) would need to garner that by
>> other means, such as reference counting or manual. We're considering
>> deprecating ~this() for classes in the future.
>>
>
> Not sure how I feel about that.

"Ecstatic" is what you're looking for.

> This has been proposed as a solution to
> some GC issue at last DConf and has been dismissed. Your post is unclear
> on why this decision has changed. There must be some new information or
> data that inform this decision.
>
> Or is it random ?

I don't remember a proposal being made that made slices of structs with destructors distinct from other slices.

> Also, what about cycle in RC things?

Resource leaks may happen in programs in any language. I'm prepared to allow leaks in certain cases, and I posit here that such cases are rare (arrays of objects that embed references to the very array they're in).

> Also, RC is good on top of GC, so
> you can collect loop, especially if we are going to RC automagically.
> That is a major issue.

That stays, and it's useful. I'm talking destructors here.

> Finally, immutable is sharable accross thread. That mean, even if we
> bypass the type system, that RC must be atomic for immutable.
> As they
> convert automatically for co,st, that mean that all const code will be
> full of atomic increment/decrement. They are bad for the CPU, and cannot
> be optimized away.

Good point. I see that as a problem, albeit a solvable one.

> That mean we are back to having a const and a mutable version of
> functions for performance reasons.

I don't think that's the case. We could and should be able to only use refcounting for truly immutable slices. (Using a bit in the counter to indicate sharing comes to mind.)

>> RCSlice!T will not convert implicitly to void[]. Explicit cast(void[])
>> will be allowed, and will ignore the reference count (so if a void[]
>> extracted from a T[] via a cast outlives all slices, dangling pointers
>> will ensue).
>>
>
> This won't work. array have a lot of magic that cannot be created as
> library. ie:
>
> RCSlice!(const T) has nothing to do with const(RCSlice!T) as far as the
> compiler is concerned.

We need to improve the language to allow for such. Did I mention it's not going to be easy?


Andrei

On 04/30/2014 10:45 PM, Andrei Alexandrescu wrote:
>>
>> An extreme one indeed, it would break a lot of my code. Every D project
>> I wrote that does networking manages memory using a class that resides
>> on the managed heap, but holds the actual wrapped data in the unmanaged
>> heap.
>
> So should I take it those classes all have destructors? -- Andrei

(Yes, those destructors free the unmanaged memory.)

On 4/30/14, 1:56 PM, Timon Gehr wrote:
>
> struct S{
>      ~this(){ /* ... */ }
>      /* ... */
> }
>
> class C{
>      S s;
> }
>
> ?

By hand, as I mentioned. -- Andrei

On 4/30/14, 1:57 PM, Vladimir Panteleev wrote:
> On Wednesday, 30 April 2014 at 20:45:57 UTC, Andrei Alexandrescu wrote:
>>> An extreme one indeed, it would break a lot of my code. Every D project
>>> I wrote that does networking manages memory using a class that resides
>>> on the managed heap, but holds the actual wrapped data in the unmanaged
>>> heap.
>>
>> So should I take it those classes all have destructors? --
>
> One class, many instances (one for every chunk of data sent or received).

The question is, how comfortable are you with today's reality that some of those instances may be never destroyed? -- Andrei

On 4/30/14, 1:57 PM, Timon Gehr wrote:
> On 04/30/2014 10:45 PM, Andrei Alexandrescu wrote:
>>>
>>> An extreme one indeed, it would break a lot of my code. Every D project
>>> I wrote that does networking manages memory using a class that resides
>>> on the managed heap, but holds the actual wrapped data in the unmanaged
>>> heap.
>>
>> So should I take it those classes all have destructors? -- Andrei
>
> (Yes, those destructors free the unmanaged memory.)

Thanks... that would need to change :o). -- Andrei

On Wednesday, 30 April 2014 at 20:59:34 UTC, Andrei Alexandrescu wrote:
> On 4/30/14, 1:57 PM, Vladimir Panteleev wrote:
>> On Wednesday, 30 April 2014 at 20:45:57 UTC, Andrei Alexandrescu wrote:
>>>> An extreme one indeed, it would break a lot of my code. Every D project
>>>> I wrote that does networking manages memory using a class that resides
>>>> on the managed heap, but holds the actual wrapped data in the unmanaged
>>>> heap.
>>>
>>> So should I take it those classes all have destructors? --
>>
>> One class, many instances (one for every chunk of data sent or received).
>
> The question is, how comfortable are you with today's reality that some of those instances may be never destroyed? -- Andrei

I'm fine with it. The proxy objects are purposefully as small as possible, to make false references (and thus, memory leaks) unlikely, even on 32 bits. If I was concerned with it, I'd have switched to reference counting as soon as it was possible.

On 04/30/2014 10:58 PM, Andrei Alexandrescu wrote:
> On 4/30/14, 1:56 PM, Timon Gehr wrote:
>>
>> struct S{
>>      ~this(){ /* ... */ }
>>      /* ... */
>> }
>>
>> class C{
>>      S s;
>> }
>>
>> ?
>
> By hand, as I mentioned. -- Andrei
>

I meant, is it going to be deprecated too?

On 4/30/14, 2:09 PM, Timon Gehr wrote:
> On 04/30/2014 10:58 PM, Andrei Alexandrescu wrote:
>> On 4/30/14, 1:56 PM, Timon Gehr wrote:
>>>
>>> struct S{
>>>      ~this(){ /* ... */ }
>>>      /* ... */
>>> }
>>>
>>> class C{
>>>      S s;
>>> }
>>>
>>> ?
>>
>> By hand, as I mentioned. -- Andrei
>>
>
> I meant, is it going to be deprecated too?

No, that will continue to be allowed. -- Andrei

On Wed, Apr 30, 2014 at 02:13:32PM -0700, Andrei Alexandrescu via Digitalmars-d wrote:
> On 4/30/14, 2:09 PM, Timon Gehr wrote:
> >On 04/30/2014 10:58 PM, Andrei Alexandrescu wrote:
> >>On 4/30/14, 1:56 PM, Timon Gehr wrote:
> >>>
> >>>struct S{
> >>>     ~this(){ /* ... */ }
> >>>     /* ... */
> >>>}
> >>>
> >>>class C{
> >>>     S s;
> >>>}
> >>>
> >>>?
> >>
> >>By hand, as I mentioned. -- Andrei
> >>
> >
> >I meant, is it going to be deprecated too?
> 
> No, that will continue to be allowed. -- Andrei

Then what is it going to do? S.~this will never get called?


T

-- 
Never wrestle a pig. You both get covered in mud, and the pig likes it.

On Wednesday, 30 April 2014 at 20:57:26 UTC, Andrei Alexandrescu wrote:
> "Ecstatic" is what you're looking for.
>

Probably...

>> This has been proposed as a solution to
>> some GC issue at last DConf and has been dismissed. Your post is unclear
>> on why this decision has changed. There must be some new information or
>> data that inform this decision.
>>
>> Or is it random ?
>
> I don't remember a proposal being made that made slices of structs with destructors distinct from other slices.
>

So the RC slice thing is what make all that worthwhile ?

>> Also, RC is good on top of GC, so
>> you can collect loop, especially if we are going to RC automagically.
>> That is a major issue.
>
> That stays, and it's useful. I'm talking destructors here.
>

Then the RCSlice do not provide any guarantee at all.

>>> RCSlice!T will not convert implicitly to void[]. Explicit cast(void[])
>>> will be allowed, and will ignore the reference count (so if a void[]
>>> extracted from a T[] via a cast outlives all slices, dangling pointers
>>> will ensue).
>>>
>>
>> This won't work. array have a lot of magic that cannot be created as
>> library. ie:
>>
>> RCSlice!(const T) has nothing to do with const(RCSlice!T) as far as the
>> compiler is concerned.
>
> We need to improve the language to allow for such. Did I mention it's not going to be easy?
>

If I understand what you mentioned, RCSlice is what make to you the ditching of destructor worthwhile. The fact that this is not doable in current D should be a showstopper for this whole thread as all that is discussed here is dependent of what solution we choose for this problem (right now we have none).