On 5/1/2014 5:43 PM, Andrei Alexandrescu wrote:
> For example, we have a File struct. It is entirely legitimate for someone to
> want to keep a File member variable in a class object. They take care of opening
> and closing it appropriately. Again, this is 100% legit code to want to write.
> Coming to them from the perspective "you are doing it wrong and there is no
> recourse for achieving what you need to do" strikes me as odd.

I meant from the perspective of expecting the GC to close the file for you. If you manually run the destructor, such as from using delete, that wouldn't be a problem.

On 5/1/14, 6:06 PM, Walter Bright wrote:
> On 5/1/2014 5:43 PM, Andrei Alexandrescu wrote:
>> For example, we have a File struct. It is entirely legitimate for
>> someone to
>> want to keep a File member variable in a class object. They take care
>> of opening
>> and closing it appropriately. Again, this is 100% legit code to want
>> to write.
>> Coming to them from the perspective "you are doing it wrong and there
>> is no
>> recourse for achieving what you need to do" strikes me as odd.
>
> I meant from the perspective of expecting the GC to close the file for
> you. If you manually run the destructor, such as from using delete, that
> wouldn't be a problem.

Or if you... close the file :o). OK, thanks for clarifying. -- Andrei

On 5/1/2014 6:19 PM, Andrei Alexandrescu wrote:
> Or if you... close the file

Hmm. Never thought of that!

On Thursday, 1 May 2014 at 22:23:46 UTC, H. S. Teoh via Digitalmars-d wrote:
> On Thu, May 01, 2014 at 03:10:04PM -0700, Walter Bright via Digitalmars-d wrote:
>> The thing is, GC is a terrible and unreliable method of managing
>> non-memory resource lifetimes. Destructors for GC objects are not
>> guaranteed to ever run. If you do have struct with a destructor as a
>> field in a class, you've got, at minimum, suspicious code and a latent
>> bug.
>
> Exactly!!! This is why I said we should ban the use of structs with
> dtors as a field in a class.

No, not in a class, but in any GC-managed object. It's unfortunate that class currently implies GC.

On 5/2/14, 3:09 AM, "Marc Schütz" <schuetzm@gmx.net>" wrote:
> On Thursday, 1 May 2014 at 22:23:46 UTC, H. S. Teoh via Digitalmars-d
> wrote:
>> On Thu, May 01, 2014 at 03:10:04PM -0700, Walter Bright via
>> Digitalmars-d wrote:
>>> The thing is, GC is a terrible and unreliable method of managing
>>> non-memory resource lifetimes. Destructors for GC objects are not
>>> guaranteed to ever run. If you do have struct with a destructor as a
>>> field in a class, you've got, at minimum, suspicious code and a latent
>>> bug.
>>
>> Exactly!!! This is why I said we should ban the use of structs with
>> dtors as a field in a class.
>
> No, not in a class, but in any GC-managed object. It's unfortunate that
> class currently implies GC.

So now it looks like dynamic arrays also can't contain structs with destructors :o). -- Andrei

On Friday, 2 May 2014 at 15:06:59 UTC, Andrei Alexandrescu wrote:
> On 5/2/14, 3:09 AM, "Marc Schütz" <schuetzm@gmx.net>" wrote:
>> On Thursday, 1 May 2014 at 22:23:46 UTC, H. S. Teoh via Digitalmars-d
>> wrote:
>>> On Thu, May 01, 2014 at 03:10:04PM -0700, Walter Bright via
>>> Digitalmars-d wrote:
>>>> The thing is, GC is a terrible and unreliable method of managing
>>>> non-memory resource lifetimes. Destructors for GC objects are not
>>>> guaranteed to ever run. If you do have struct with a destructor as a
>>>> field in a class, you've got, at minimum, suspicious code and a latent
>>>> bug.
>>>
>>> Exactly!!! This is why I said we should ban the use of structs with
>>> dtors as a field in a class.
>>
>> No, not in a class, but in any GC-managed object. It's unfortunate that
>> class currently implies GC.
>
> So now it looks like dynamic arrays also can't contain structs with destructors :o). -- Andrei

Well, that would be the logical consequence...

But my main point was actually this:
Don't disallow destructors on classes just because they are classes, but disallow them when they are not guaranteed to be called (or calling them is troublesome because of multi-threading), i.e. GC.

On 5/2/14, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> So now it looks like dynamic arrays also can't contain structs with destructors :o). -- Andrei

I suggest tracking these ideas on a wiki page so we don't lose track of what the latest proposal is (we'll run in circles otherwise).

These threads tend to literally explode with posts from everyone. :)

On 2014-05-02 17:38, "Marc Schütz" <schuetzm@gmx.net>" wrote:

> But my main point was actually this:
> Don't disallow destructors on classes just because they are classes, but
> disallow them when they are not guaranteed to be called (or calling them
> is troublesome because of multi-threading), i.e. GC.

Tango for D1 added a "dispose" method to Object. This method was called when "delete" or "scope" was used.

-- 
/Jacob Carlborg

On Friday, 2 May 2014 at 15:06:59 UTC, Andrei Alexandrescu wrote:
> So now it looks like dynamic arrays also can't contain structs with destructors :o). -- Andrei

Well, that's always been the case, and even worst, since in a dynamic array, destructor are guaranteed to *never* be run. Furthermore, given the "append causes relocation which duplicates", you are almost *guaranteed* to leak your destructors. You just can't keep track of the usage of a "naked" dynamic array.

This usually comes as a great surprise to users in ".learn". It's also the reason why using "File[]" never ends well...

On Fri, May 02, 2014 at 09:03:15PM +0000, monarch_dodra via Digitalmars-d wrote:
> On Friday, 2 May 2014 at 15:06:59 UTC, Andrei Alexandrescu wrote:
> >So now it looks like dynamic arrays also can't contain structs with destructors :o). -- Andrei
> 
> Well, that's always been the case, and even worst, since in a dynamic array, destructor are guaranteed to *never* be run. Furthermore, given the "append causes relocation which duplicates", you are almost *guaranteed* to leak your destructors. You just can't keep track of the usage of a "naked" dynamic array.
> 
> This usually comes as a great surprise to users in ".learn". It's also the reason why using "File[]" never ends well...

This is why I'm unhappy with the way this is going. Current behaviour of structs with dtors is already fragile enough, now we're pulling the rug out from under classes as well. So that will be yet another case where dtors won't work as expected.

I'm getting the feeling that dtors were bolted on as an afterthought, and only works properly for a very narrow spectrum of use cases. Rather than expand the usable cases, we're proposing to reduce them (by getting rid of class dtors). I can't see *this* ending well either. :-(


T

-- 
Democracy: The triumph of popularity over principle. -- C.Bond