On Saturday, 27 June 2015 at 12:28:26 UTC, Kagamin wrote:
> On Friday, 26 June 2015 at 18:27:34 UTC, Maxime Chevalier-Boisvert wrote:
>> I seem to have run into a heisenbug involving destructors and the GC. I'm kind of stuck at this point and need help tracking down the issue.
>
> BTW, how GC performance is doing? Etienne is experimenting with thread local GC: http://forum.dlang.org/post/nfuzudyoatryapcwxquu@forum.dlang.org which also proved to be faster. But only if single-threaded GC is good enough for you, which normally should be given single-threaded model of javascript.

The new keyword can leverage the shared keyword to place certain objects in a shared GC, which can coexist with the local GC without fundamental changes. ie std.concurrency already requires that you pass shared objects, but casting won't cut it anymore you'll actually have to duplicate the object on the shared GC with .sdup or create it there with new shared. I don't need a shared GC right now so I'm not pushing too much for it, I'm satisfied with keeping a pointer of the object alive in the thread it was created and that's all a thread local GC really requires for concurrency to work

On 6/26/15 11:38 PM, Brian Schott wrote:
> On Saturday, 27 June 2015 at 03:16:35 UTC, rsw0x wrote:
>> calling destroy on a pointer should either be fixed or be an error,
>> that should not be allowed to happen.
>
> Completely agreed. Calling destroy() on a pointer has been incorrect
> EVERY time I've seen it done.

I'd say if you want to see cases where it was done correctly, change the behavior and watch the complaints come in ;)

Wouldn't destroying the pointer target make an assumption about ownership?

Consider a struct that contains a pointer:

struct S
{
   T *x;
}

destroy's algorithm for this struct is to call destroy on all of the members, then set to S.init. But what if S is just *referencing* that T, and doesn't *own* it? Isn't this the wrong thing to do?

I agree it's inconsistent with class references. How to make it consistent isn't as easy to decide. For me, it's the class destruction which is incorrect. Consider that destroy is consistent with scope destruction for every type except for classes:

class C {}
struct S {}

{
   C c = new C;
   S s;
   S *s2 = new S;
} // calls s.dtor, does not call c.dtor or s2.dtor

And what about arrays? Should calling destroy on an array call destroy on all of the elements (it currently doesn't)?

If I were to design destroy from scratch, I'd make destroy, and destroyRef (which destroys referenced data via pointer or class).

-Steve

On Tuesday, 30 June 2015 at 13:01:46 UTC, Steven Schveighoffer wrote:
> On 6/26/15 11:38 PM, Brian Schott wrote:
>> On Saturday, 27 June 2015 at 03:16:35 UTC, rsw0x wrote:
>>> calling destroy on a pointer should either be fixed or be an error,
>>> that should not be allowed to happen.
>>
>> Completely agreed. Calling destroy() on a pointer has been incorrect
>> EVERY time I've seen it done.
>
> I'd say if you want to see cases where it was done correctly, change the behavior and watch the complaints come in ;)
>
> Wouldn't destroying the pointer target make an assumption about ownership?
>
> Consider a struct that contains a pointer:
>
> struct S
> {
>    T *x;
> }
>
> destroy's algorithm for this struct is to call destroy on all of the members, then set to S.init. But what if S is just *referencing* that T, and doesn't *own* it? Isn't this the wrong thing to do?
>
> I agree it's inconsistent with class references. How to make it consistent isn't as easy to decide. For me, it's the class destruction which is incorrect. Consider that destroy is consistent with scope destruction for every type except for classes:
>
> class C {}
> struct S {}
>
> {
>    C c = new C;
>    S s;
>    S *s2 = new S;
> } // calls s.dtor, does not call c.dtor or s2.dtor
>
> And what about arrays? Should calling destroy on an array call destroy on all of the elements (it currently doesn't)?
>
> If I were to design destroy from scratch, I'd make destroy, and destroyRef (which destroys referenced data via pointer or class).
>
> -Steve

I don't think there's a problem with destroy in the first place. The problem is that it's being advertised as calling the destructors:

http://dlang.org/library/object/type_info.destroy.html
http://dlang.org/library/object/destroy.html

The function would need a documentation section itself, since it's being advertised as a replacement for `delete` and expected to do the same wherever there's something to read about it.

On Tuesday, 30 June 2015 at 14:04:45 UTC, Etienne wrote:
> On Tuesday, 30 June 2015 at 13:01:46 UTC, Steven Schveighoffer wrote:
>> [...]
>
> I don't think there's a problem with destroy in the first place. The problem is that it's being advertised as calling the destructors:
>
> http://dlang.org/library/object/type_info.destroy.html
> http://dlang.org/library/object/destroy.html
>
> The function would need a documentation section itself, since it's being advertised as a replacement for `delete` and expected to do the same wherever there's something to read about it.

We probably just need a new page in the `D Reference` about Lifetime. Documenting the general behavior and good practices of anything that manages lifetime, e.g. malloc, free, delete, destroy, new, pointers, classes, base types, etc.

On 6/30/15 10:04 AM, Etienne wrote:

> I don't think there's a problem with destroy in the first place. The
> problem is that it's being advertised as calling the destructors:

It does for value types and for class references.

-Steve

On Tuesday, 30 June 2015 at 17:10:41 UTC, Steven Schveighoffer wrote:
> On 6/30/15 10:04 AM, Etienne wrote:
>
>> I don't think there's a problem with destroy in the first place. The
>> problem is that it's being advertised as calling the destructors:
>
> It does for value types and for class references.
>
> -Steve

Yeah well the types that don't get finalized by it need to be listed somewhere