On Friday, 29 August 2014 at 06:39:20 UTC, monarch_dodra wrote:
> On Friday, 29 August 2014 at 02:38:54 UTC, H. S. Teoh via Digitalmars-d wrote:
>> Maybe a more relevant question might be, is there any existing code that
>> *isn't* broken by structs not being destructed? (D-structed, har har.)
>
> Well, this new change *could* greatly increase the amount of "allocation during destruction" errors we are getting. I've seen a fair share of these in learn, whereas a class destructor allocates.
>
> Structs will now also be more vulnerable to this problem too. I wouldn't be surprised if this pull instantaneously introduced a fair amount of breakage in client code.

Jacob Carlborg just recently brought this up in another thread. Isn't it kind of consensus that calling a destructor from the GC is not a good idea because of the restrictions that apply in this context? Andrei even wanted to deprecate destructors for classes because of this. Maybe a better direction would be to separate the concepts of destruction and finalization, and introduce two kinds of "destructors" for them.

On Friday, 29 August 2014 at 09:16:36 UTC, monarch_dodra wrote:
> On Friday, 29 August 2014 at 09:08:07 UTC, Andrej Mitrovic via Digitalmars-d wrote:
>> On 8/29/14, ponce via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>> On Friday, 29 August 2014 at 02:21:07 UTC, Andrei Alexandrescu
>>> wrote:
>>>> Dear community, are you ready for this?
>>>
>>> Yes! Whatever needs be done.
>>
>> Yeah destructors are a sore pain when they're unreliable. "May or may
>> not be called" is just an awful semantic.
>
> That won't really change though, will it? AFAIK, it'll become: "will eventually be called at some unspecified point it time. The program may terminate before that happens, at which point, the destructor will never be called."
>
> ...right?

Yes, there's no way around this with a conservative GC.

On 29/08/14 12:53, "Marc Schütz" <schuetzm@gmx.net>" wrote:

> Jacob Carlborg just recently brought this up in another thread. Isn't it
> kind of consensus that calling a destructor from the GC is not a good
> idea because of the restrictions that apply in this context? Andrei even
> wanted to deprecate destructors for classes because of this. Maybe a
> better direction would be to separate the concepts of destruction and
> finalization, and introduce two kinds of "destructors" for them.

Yeah, Tango for D1 added a new method, "dispose", to Object. It's called when "delete" or "scope" is used.

-- 
/Jacob Carlborg

On Friday, 29 August 2014 at 02:21:07 UTC, Andrei Alexandrescu wrote:
> Dear community, are you ready for this?

Yes.

> This is a significant change of behavior. Should we provide a temporary flag or attribute to disable it?

I don't think so, it will just hinder adoption. If people don't want it they can stay with 2.066.

On Friday, 29 August 2014 at 14:24:34 UTC, Peter Alexander wrote:
> On Friday, 29 August 2014 at 02:21:07 UTC, Andrei Alexandrescu wrote:
>> Dear community, are you ready for this?
>
> Yes.
>
>> This is a significant change of behavior. Should we provide a temporary flag or attribute to disable it?
>
> I don't think so, it will just hinder adoption. If people don't want it they can stay with 2.066.

Especially seeing as now we are doing patch releases.

On 8/28/14, 11:13 PM, ketmar via Digitalmars-d wrote:
> On Thu, 28 Aug 2014 19:21:04 -0700
> Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com>
> wrote:
>
>> Dear community, are you ready for this?
> yes, yes and yes!
>

You forgot the Oxford comma :o). -- Andrei

On 8/29/2014 12:41 AM, monarch_dodra wrote:
> Questions:
> - Can and will this work for arrays of structs?
> - When doing manual GC allocations (for whatever reason), how can we
> later tell the GC what destructor to call?

Yes, this does work for arrays of structs. Provided that you've passed in the type info for the struct when doing the manual allocation, it should call the destructor without anything extra needing to be done on the user's part.

> These questions combined are really aimed at Appender: I'm curious at if
> and how any changes will have to be made to it.

Appender already uses the type info's destroy, so it shouldn't have any issues, as I already had to account for that.

> Also question: Will this play nice wit exiting code that manually
> destroys GC allocated structs?

As I mentioned elsewhere, as long as the existing code is calling destroy, and not calling the finalizer directly, then yes, it will play nice, and only call the finalizer once.

On Friday, 29 August 2014 at 18:12:04 UTC, Orvid King wrote:
> On 8/29/2014 12:41 AM, monarch_dodra wrote:
>> Questions:
>> - Can and will this work for arrays of structs?
>> - When doing manual GC allocations (for whatever reason), how can we
>> later tell the GC what destructor to call?
>
> Yes, this does work for arrays of structs. Provided that you've passed in the type info for the struct when doing the manual allocation, it should call the destructor without anything extra needing to be done on the user's part.

Hum... by "manual" memory allocation. I meant this:

GC.qalloc(newlen * T.sizeof, blockAttribute!T);

That's what Appender does. Unless I'm mistaken, the Type info is not passed here? Furthermore, the Type info *can't* be passed...?

> > These questions combined are really aimed at Appender: I'm
> curious at if
> > and how any changes will have to be made to it.
>
> Appender already uses the type info's destroy, so it shouldn't have any issues, as I already had to account for that.

This is news to me. Appender does not destroy anything. It makes no call to delete/destroy/release or whatnot. It simply just keeps allocating away.

> > Also question: Will this play nice wit exiting code that
> manually
> > destroys GC allocated structs?
>
> As I mentioned elsewhere, as long as the existing code is calling destroy, and not calling the finalizer directly, then yes, it will play nice, and only call the finalizer once.

OK. Nice. Thanks.

BTW: If Appender is "broken", that's OK (in the sense that it won't be any more "broken" than before). I just want as much information as possible about what I (we) will need to do to update it.

In particular, Appender has an optimization that skips postblit to "relocate" when possible. If destructions start happening, then we'll need to make sure we first reset to "T.init", or we'll risk destroying a non-postblitted copy (which could be catastrophic in the case of RC'ed structs).

On Friday, 29 August 2014 at 18:12:04 UTC, Orvid King wrote:
> On 8/29/2014 12:41 AM, monarch_dodra wrote:
>> Questions:
>> - Can and will this work for arrays of structs?
>> - When doing manual GC allocations (for whatever reason), how can we
>> later tell the GC what destructor to call?
>
> Yes, this does work for arrays of structs. Provided that you've passed in the type info for the struct when doing the manual allocation, it should call the destructor without anything extra needing to be done on the user's part.

Hum... by "manual" memory allocation. I meant this:

GC.qalloc(newlen * T.sizeof, blockAttribute!T);

That's what Appender does. Unless I'm mistaken, the Type info is not passed here? Furthermore, the Type info *can't* be passed...?

> > These questions combined are really aimed at Appender: I'm
> curious at if
> > and how any changes will have to be made to it.
>
> Appender already uses the type info's destroy, so it shouldn't have any issues, as I already had to account for that.

This is news to me. Appender does not destroy anything. It makes no call to delete/destroy/release or whatnot. It simply just keeps allocating away.

> > Also question: Will this play nice wit exiting code that
> manually
> > destroys GC allocated structs?
>
> As I mentioned elsewhere, as long as the existing code is calling destroy, and not calling the finalizer directly, then yes, it will play nice, and only call the finalizer once.

OK. Nice. Thanks.

BTW: If Appender is "broken", that's OK (in the sense that it won't be any more "broken" than before). I just want as much information as possible about what I (we) will need to do to update it.

In particular, Appender has an optimization that skips postblit to "relocate" when possible. If destructions start happening, then we'll need to make sure we first reset to "T.init", or we'll risk destroying a non-postblitted copy (which could be catastrophic in the case of RC'ed structs).

On 8/29/14, 2:16 AM, monarch_dodra wrote:
> On Friday, 29 August 2014 at 09:08:07 UTC, Andrej Mitrovic via
> Digitalmars-d wrote:
>> On 8/29/14, ponce via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>> On Friday, 29 August 2014 at 02:21:07 UTC, Andrei Alexandrescu
>>> wrote:
>>>> Dear community, are you ready for this?
>>>
>>> Yes! Whatever needs be done.
>>
>> Yeah destructors are a sore pain when they're unreliable. "May or may
>> not be called" is just an awful semantic.
>
> That won't really change though, will it? AFAIK, it'll become: "will
> eventually be called at some unspecified point it time. The program may
> terminate before that happens, at which point, the destructor will never
> be called."
>
> ....right?

Right, and reasonable. -- Andrei