Walter and I have had a long chat in which we figured our current offering of abstractions could be improved. Here are some thoughts. There's a lot of work ahead of us on that and I wanted to make sure we're getting full community buy-in and backup.

First off, we're considering eliminating destructor calls from within the GC entirely. It makes for a faster and better GC, but the real reason here is that destructors are philosophically bankrupt in a GC environment. I think there's no need to argue that in this community. The GC never guarantees calling destructors even today, so this decision would be just a point in the definition space (albeit an extreme one).

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.

Also, we're considering a revamp of built-in slices, as follows. Slices of types without destructors stay as they are.

Slices T[] of structs with destructors shall be silently lowered into RCSlice!T, defined inside object.d. That type would occupy THREE words, one of which being a pointer to a reference count. That type would redefine all slice primitives to update the reference count accordingly.

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

I foresee any number of theoretical and practical issues with this approach. Let's discuss some of them here.


Thanks,

Andrei

On Wednesday, 30 April 2014 at 20:21:33 UTC, Andrei Alexandrescu wrote:
> Walter and I have had a long chat in which we figured our current offering of abstractions could be improved. Here are some thoughts. There's a lot of work ahead of us on that and I wanted to make sure we're getting full community buy-in and backup.
>
> First off, we're considering eliminating destructor calls from within the GC entirely. It makes for a faster and better GC, but the real reason here is that destructors are philosophically bankrupt in a GC environment. I think there's no need to argue that in this community. The GC never guarantees calling destructors even today, so this decision would be just a point in the definition space (albeit an extreme one).

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. It has a number of advantages over other approaches, and I've posted it to the announce group, but the idea didn't seem to catch on.

https://github.com/CyberShadow/ae/blob/master/sys/data.d

I could migrate the concept to use reference counting (it was implemented in D1, before reference counting was possible), but that's my situation regarding breaking existing code.

On Wednesday, 30 April 2014 at 20:21:33 UTC, Andrei Alexandrescu wrote:
> We're considering deprecating ~this() for classes in the future.
>
> [...]
>
> Slices T[] of structs with destructors shall be silently lowered into RCSlice!T, defined inside object.d

I'm sure instead of outright deprecating destructor for class, we could just store them in a RCClass!C (which would be 2 words big).

If you can get the scheme working with slices of structs with destructors, I don't see why the same scheme couldn't work with Class'es too.

On 4/30/14, 1:31 PM, Vladimir Panteleev wrote:
> On Wednesday, 30 April 2014 at 20:21:33 UTC, Andrei Alexandrescu wrote:
>> Walter and I have had a long chat in which we figured our current
>> offering of abstractions could be improved. Here are some thoughts.
>> There's a lot of work ahead of us on that and I wanted to make sure
>> we're getting full community buy-in and backup.
>>
>> First off, we're considering eliminating destructor calls from within
>> the GC entirely. It makes for a faster and better GC, but the real
>> reason here is that destructors are philosophically bankrupt in a GC
>> environment. I think there's no need to argue that in this community.
>> The GC never guarantees calling destructors even today, so this
>> decision would be just a point in the definition space (albeit an
>> extreme one).
>
> 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

On Wednesday, 30 April 2014 at 20:21:33 UTC, Andrei Alexandrescu wrote:
> Walter and I have had a long chat in which we figured our current offering of abstractions could be improved. Here are some thoughts. There's a lot of work ahead of us on that and I wanted to make sure we're getting full community buy-in and backup.
>

Still no consideration for isolated.

> First off, we're considering eliminating destructor calls from within the GC entirely. It makes for a faster and better GC, but the real reason here is that destructors are philosophically bankrupt in a GC environment. I think there's no need to argue that in this community. The GC never guarantees calling destructors even today, so this decision would be just a point in the definition space (albeit an extreme one).
>
> 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. 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 ?

Also, what about cycle in RC things ? 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.

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.

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

> Also, we're considering a revamp of built-in slices, as follows. Slices of types without destructors stay as they are.
>
> Slices T[] of structs with destructors shall be silently lowered into RCSlice!T, defined inside object.d. That type would occupy THREE words, one of which being a pointer to a reference count. That type would redefine all slice primitives to update the reference count accordingly.
>
> 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.

This is why we still don't have any library that provides collection properly. One of the best is probably dcollection, and it has no solution for that problem.

I'd like to see some core issue like that one before changing everything on top of it. When the whole thing is built on goo, readjusting the top to make it point upward is doomed to create the Pisa tower. Fine for tourists, but not very practical nor useful.

On 4/30/14, 1:33 PM, monarch_dodra wrote:
> On Wednesday, 30 April 2014 at 20:21:33 UTC, Andrei Alexandrescu wrote:
>> We're considering deprecating ~this() for classes in the future.
>>
>> [...]
>>
>> Slices T[] of structs with destructors shall be silently lowered into
>> RCSlice!T, defined inside object.d
>
> I'm sure instead of outright deprecating destructor for class, we could
> just store them in a RCClass!C (which would be 2 words big).

That's an interesting idea, but the whole notion of converting to Object etc. makes the concept difficult (unless we define another root etc).

Andrei

On 4/30/14, 1:46 PM, deadalnix wrote:
> Still no consideration for isolated.

https://github.com/D-Programming-Language/dmd/pull/3452 may be of interest to you. -- Andrei

On 04/30/2014 10:21 PM, Andrei Alexandrescu wrote:
> Walter and I have had a long chat in which we figured our current
> offering of abstractions could be improved. Here are some thoughts.
> There's a lot of work ahead of us on that and I wanted to make sure
> we're getting full community buy-in and backup.
>
> First off, we're considering eliminating destructor calls from within
> the GC entirely. It makes for a faster and better GC, but the real
> reason here is that destructors are philosophically bankrupt in a GC
> environment. I think there's no need to argue that in this community.
> The GC never guarantees calling destructors even today, so this decision
> would be just a point in the definition space (albeit an extreme one).
>
> 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.
> ...

struct S{
    ~this(){ /* ... */ }
    /* ... */
}

class C{
    S s;
}

?

> Also, we're considering a revamp of built-in slices, as follows. Slices
> of types without destructors stay as they are.
>
> Slices T[] of structs with destructors shall be silently lowered into
> RCSlice!T, defined inside object.d. That type would occupy THREE words,
> one of which being a pointer to a reference count. That type would
> redefine all slice primitives to update the reference count accordingly.
>
> 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).
>
> I foresee any number of theoretical and practical issues with this
> approach. Let's discuss some of them here.
> ...

struct S{
    ~this(){ /* ... */ }
}

class C{
    S[] s;
    this(S[] s){ /* ... */ }
}

void main(){
    new C(buildSs());
    // memory leak
}

Also, cycles.

On Wednesday, 30 April 2014 at 20:49:30 UTC, Andrei Alexandrescu wrote:
> On 4/30/14, 1:46 PM, deadalnix wrote:
>> Still no consideration for isolated.
>
> https://github.com/D-Programming-Language/dmd/pull/3452 may be of interest to you. -- Andrei

I already commented on past similar proposal. These are piling up more and more hacks to achieve roughly the same thing, badly. This makes it impossible to provide a 3rd party implementation that is compliant, is guaranteed to ends up in a nightmarish explosion of special cases, or to be vastly underpowered.

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