> 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?