> Now I don't have a good name. Finalize isn't right, and neither is
> dispose...

what about "invalidate"?

On 5/25/12 12:37 PM, Mirko Pilger wrote:
>> Now I don't have a good name. Finalize isn't right, and neither is
>> dispose...
>
> what about "invalidate"?

Whatever it is, I should say I'll be very strongly opposed to any proposal if it is about as controversial as "clear".

Andrei

On 05/25/2012 05:42 PM, Steven Schveighoffer wrote:
> On Fri, 25 May 2012 11:37:52 -0400, Steven Schveighoffer
> <schveiguy@yahoo.com> wrote:
>
>> On Fri, 25 May 2012 11:28:07 -0400, Alex Rønne Petersen
>> <alex@lycus.org> wrote:
>>
>>> On 25-05-2012 17:23, Steven Schveighoffer wrote:
>>>> On Fri, 25 May 2012 11:03:33 -0400, Alex Rønne Petersen
>>>> <alex@lycus..org> wrote:
>>>>
>>>>> On 25-05-2012 16:56, Steven Schveighoffer wrote:
>>>>>>
>>>>>> Wow, you're right, it's not documented. That should be fixed!
>>>>>
>>>>> Before we do, we should deprecate clear and rename it to finalize,
>>>>> though.
>>>>
>>>> I don't like finalize because it's not a finalizer.
>>>>
>>>> I think we should mimic other languages that have a finalizer and a
>>>> deterministic dispose function.
>>>>
>>>> -Steve
>>>
>>> But it calls rt_finalize...?
>>
>> Yeah, because non-deterministic destruction is part of deterministic
>> destruction.
>>
>> finalize -> destroy non-gc resources
>> dispose -> 1. do deterministic destruction involving possible GC
>> resources 2. call finalize.
>>
>> e.g. a buffered file:
>>
>> finalize -> close the file handle
>> dispose -> flush the GC allocated buffer into the handle, then close
>> the handle
>
> I take it back, dispose is no good. That should be the name of the
> deterministic destructor in the object.
>
> Now I don't have a good name. Finalize isn't right, and neither is
> dispose...
>
> -Steve

blank, destroy, trash, dump, zero, bleach, cleanup,
sanitize, burn, nuke, eject, jetisson, discard,
landfill, waste, litter, debris, recycle, obliterate,
annihilate, eradicate, expunge, finish, ravage, wipe,
zap, abolish, decimate, demolish, massacre, murder,
ruin, slaughter, quash, scrub, splat

On Fri, May 25, 2012 at 1:34 PM, sclytrack <sclytrack@iq87.fr> wrote:

> On 05/25/2012 05:42 PM, Steven Schveighoffer wrote:
>
>> On Fri, 25 May 2012 11:37:52 -0400, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
>>
>>  On Fri, 25 May 2012 11:28:07 -0400, Alex Rønne Petersen
>>> <alex@lycus.org> wrote:
>>>
>>>  On 25-05-2012 17:23, Steven Schveighoffer wrote:
>>>>
>>>>> On Fri, 25 May 2012 11:03:33 -0400, Alex Rønne Petersen <alex@lycus..org> wrote:
>>>>>
>>>>>  On 25-05-2012 16:56, Steven Schveighoffer wrote:
>>>>>>
>>>>>>>
>>>>>>> Wow, you're right, it's not documented. That should be fixed!
>>>>>>>
>>>>>>
>>>>>> Before we do, we should deprecate clear and rename it to finalize, though.
>>>>>>
>>>>>
>>>>> I don't like finalize because it's not a finalizer.
>>>>>
>>>>> I think we should mimic other languages that have a finalizer and a deterministic dispose function.
>>>>>
>>>>> -Steve
>>>>>
>>>>
>>>> But it calls rt_finalize...?
>>>>
>>>
>>> Yeah, because non-deterministic destruction is part of deterministic destruction.
>>>
>>> finalize -> destroy non-gc resources
>>> dispose -> 1. do deterministic destruction involving possible GC
>>> resources 2. call finalize.
>>>
>>> e.g. a buffered file:
>>>
>>> finalize -> close the file handle
>>> dispose -> flush the GC allocated buffer into the handle, then close
>>> the handle
>>>
>>
>> I take it back, dispose is no good. That should be the name of the deterministic destructor in the object.
>>
>> Now I don't have a good name. Finalize isn't right, and neither is dispose...
>>
>> -Steve
>>
>
> blank, destroy, trash, dump, zero, bleach, cleanup,
> sanitize, burn, nuke, eject, jetisson, discard,
> landfill, waste, litter, debris, recycle, obliterate,
> annihilate, eradicate, expunge, finish, ravage, wipe,
> zap, abolish, decimate, demolish, massacre, murder,
> ruin, slaughter, quash, scrub, splat
>
>
>
I'm partial to defenestrate().

On Friday, 25 May 2012 at 20:16:32 UTC, Brad Anderson wrote:
> On Fri, May 25, 2012 at 1:34 PM, sclytrack <sclytrack@iq87.fr>
>> blank, destroy, trash, dump, zero, bleach, cleanup,
>> sanitize, burn, nuke, eject, jetisson, discard,
>> landfill, waste, litter, debris, recycle, obliterate,
>> annihilate, eradicate, expunge, finish, ravage, wipe,
>> zap, abolish, decimate, demolish, massacre, murder,
>> ruin, slaughter, quash, scrub, splat
>>
>>
>>
> I'm partial to defenestrate().

One for the Doctor Who fans among us:

exterminate().

On Friday, 25 May 2012 at 20:41:10 UTC, John Chapman wrote:
> On Friday, 25 May 2012 at 20:16:32 UTC, Brad Anderson wrote:
>> On Fri, May 25, 2012 at 1:34 PM, sclytrack <sclytrack@iq87.fr>
>>> blank, destroy, trash, dump, zero, bleach, cleanup,
>>> sanitize, burn, nuke, eject, jetisson, discard,
>>> landfill, waste, litter, debris, recycle, obliterate,
>>> annihilate, eradicate, expunge, finish, ravage, wipe,
>>> zap, abolish, decimate, demolish, massacre, murder,
>>> ruin, slaughter, quash, scrub, splat
>>>
>>>
>>>
>> I'm partial to defenestrate().
>
> One for the Doctor Who fans among us:
>
> exterminate().

or we could just, uh, bring back delete...

On Saturday, May 26, 2012 02:30:57 Mehrdad wrote:
> On Friday, 25 May 2012 at 20:41:10 UTC, John Chapman wrote:
> > On Friday, 25 May 2012 at 20:16:32 UTC, Brad Anderson wrote:
> >> On Fri, May 25, 2012 at 1:34 PM, sclytrack <sclytrack@iq87.fr>
> >> 
> >>> blank, destroy, trash, dump, zero, bleach, cleanup,
> >>> sanitize, burn, nuke, eject, jetisson, discard,
> >>> landfill, waste, litter, debris, recycle, obliterate,
> >>> annihilate, eradicate, expunge, finish, ravage, wipe,
> >>> zap, abolish, decimate, demolish, massacre, murder,
> >>> ruin, slaughter, quash, scrub, splat
> >> 
> >> I'm partial to defenestrate().
> > 
> > One for the Doctor Who fans among us:
> > 
> > exterminate().
> 
> or we could just, uh, bring back delete...

clear and delete are very different things. It was definitely decided that we'd be better off without delete. It's going for good. Renaming clear to something that doesn't conflict so easily with more benign functions is completely different from bringing back delete. Bringing back delete isn't even on the table at this point.

- Jonathan M Davis

Would you mind explaining the difference between clear(), delete, and __dtor/etc? I think it's a little confusing for me.

On Saturday, May 26, 2012 04:04:51 Mehrdad wrote:
> Would you mind explaining the difference between clear(), delete, and __dtor/etc? I think it's a little confusing for me.

clear destroys the object (by calling its finalizer or destructor) and then in the case of classes, it zeroes out its vtable so that if you accidentally the object after clearing it, it'll blow up rather than getting weird, non- deterministic behavior. In the case of structs, I think that it puts the object in its init state, but I'm not sure.

clear does _not_ free the object's memory. It merely destroys the object so that whatever other resources it references can be released (or just unreferenced in the case of GC heap allocated objects that it references).

delete does what it does in C++. It destroys the object and then frees the memory. It was decided that having a language construct which freed memory on the GC heap was too dangerous and error-prone and shouldn't be encouraged, so it's being removed. It's still quite possible however, to create a function which destroys and object and then tells the GC to free that object's memory using the stuff in core.memory.

__dtor is simply the object's destructor. Calling it calls that function. However, I don't believe that it destroys what the object references (since that would require doing more than simply calling the destructor). As I recall, you have to do something else which is a bit involved to do that. There was a discussion on it recently, but I don't recall the details unfortunately.

In the long run, I expect that anyone who really wants to use something akin to delete will likely use custom allocators (e.g. using malloc and free) rather than using the GC heap, possibly with some sort of ref-counting. So, you'd get something like

//non-ref-counted
auto a = ca.allocate!MyClass(args);
ca.deallocate(a);

or

//ref-counted
{
    auto a = ca.allocate!MyClass(args);
}
//a has left scope, so its ref-count reach zero, and it was destroyed

Obviously we don't have the custom allocator stuff fully ironed out yet though. Andrei has been working on those, but he's been a bit swamped, so who knows when we'll see them.

- Jonathan M Davis

Okay, thanks for the explanation.


So basically, clear() just calls __dtor(), and then zeros out the vtable?

I don't understand what you mean by "I don't believe that it destroys what the object references"... why should clear() ever destroy anything except the object that it's destroying?