=?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <alex lycus.org> writes:

So I was writing a container class and in some test code, I called 
container.clear(). Reasonable enough, right? Hell, it even compiled!

Turns out, my program completely broke at runtime. Apparently, I'd 
forgotten to implement clear() on my container class, and 
*object.clear() was being called instead*.

I don't blame UFCS for this. It just happened to be the reason this 
compiled at all. But, what I do think is: clear is the *ABSOLUTELY MOST 
HORRIBLE NAME EVER* for a function that actually finalizes and zeroes an 
object. Did it not seem obvious to call it, I don't know, *finalize*? 
And even ignoring the naming, having a symbol called clear in the 
'global' namespace is absolute insanity.

Am I the only person with this opinion?

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org

Dmitry Olshansky <dmitry.olsh gmail.com> writes:

On 25.05.2012 17:04, Alex Rønne Petersen wrote:
 So I was writing a container class and in some test code, I called
 container.clear(). Reasonable enough, right? Hell, it even compiled!

 Turns out, my program completely broke at runtime. Apparently, I'd
 forgotten to implement clear() on my container class, and
 *object.clear() was being called instead*.

 I don't blame UFCS for this. It just happened to be the reason this
 compiled at all. But, what I do think is: clear is the *ABSOLUTELY MOST
 HORRIBLE NAME EVER* for a function that actually finalizes and zeroes an
 object. Did it not seem obvious to call it, I don't know, *finalize*?
 And even ignoring the naming, having a symbol called clear in the
 'global' namespace is absolute insanity.

 Am I the only person with this opinion?

No, there are thousands like you. Let's call clear "nuke", breaking TDPL 
and saving the day. :)

P.S. Obviously first clear goes through normal deprecation cycle.

-- 
Dmitry Olshansky

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 5/25/12 8:06 AM, Dmitry Olshansky wrote:
 On 25.05.2012 17:04, Alex Rønne Petersen wrote:
 So I was writing a container class and in some test code, I called
 container.clear(). Reasonable enough, right? Hell, it even compiled!

 Turns out, my program completely broke at runtime. Apparently, I'd
 forgotten to implement clear() on my container class, and
 *object.clear() was being called instead*.

 I don't blame UFCS for this. It just happened to be the reason this
 compiled at all. But, what I do think is: clear is the *ABSOLUTELY MOST
 HORRIBLE NAME EVER* for a function that actually finalizes and zeroes an
 object. Did it not seem obvious to call it, I don't know, *finalize*?
 And even ignoring the naming, having a symbol called clear in the
 'global' namespace is absolute insanity.

 Am I the only person with this opinion?

 No, there are thousands like you. Let's call clear "nuke", breaking TDPL
 and saving the day. :)

 P.S. Obviously first clear goes through normal deprecation cycle.

Since this is a recurring issue we should probably change the name.

Andrei

deadalnix <deadalnix gmail.com> writes:

Le 25/05/2012 17:00, Andrei Alexandrescu a écrit :
 On 5/25/12 8:06 AM, Dmitry Olshansky wrote:
 On 25.05.2012 17:04, Alex Rønne Petersen wrote:
 So I was writing a container class and in some test code, I called
 container.clear(). Reasonable enough, right? Hell, it even compiled!

 Turns out, my program completely broke at runtime. Apparently, I'd
 forgotten to implement clear() on my container class, and
 *object.clear() was being called instead*.

 I don't blame UFCS for this. It just happened to be the reason this
 compiled at all. But, what I do think is: clear is the *ABSOLUTELY MOST
 HORRIBLE NAME EVER* for a function that actually finalizes and zeroes an
 object. Did it not seem obvious to call it, I don't know, *finalize*?
 And even ignoring the naming, having a symbol called clear in the
 'global' namespace is absolute insanity.

 Am I the only person with this opinion?

 No, there are thousands like you. Let's call clear "nuke", breaking TDPL
 and saving the day. :)

 P.S. Obviously first clear goes through normal deprecation cycle.

 Since this is a recurring issue we should probably change the name.

 Andrei

It has already been suggested, but finalize is something that is 
explicit, and it is already used in other languages. We should go that 
way IMO.

deadalnix <deadalnix gmail.com> writes:

Le 25/05/2012 15:04, Alex Rønne Petersen a écrit :
 So I was writing a container class and in some test code, I called
 container.clear(). Reasonable enough, right? Hell, it even compiled!

 Turns out, my program completely broke at runtime. Apparently, I'd
 forgotten to implement clear() on my container class, and
 *object.clear() was being called instead*.

 I don't blame UFCS for this. It just happened to be the reason this
 compiled at all. But, what I do think is: clear is the *ABSOLUTELY MOST
 HORRIBLE NAME EVER* for a function that actually finalizes and zeroes an
 object. Did it not seem obvious to call it, I don't know, *finalize*?
 And even ignoring the naming, having a symbol called clear in the
 'global' namespace is absolute insanity.

 Am I the only person with this opinion?

Why is UFCS involved here ?

=?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <alex lycus.org> writes:

On 25-05-2012 15:17, deadalnix wrote:
 Le 25/05/2012 15:04, Alex Rønne Petersen a écrit :
 So I was writing a container class and in some test code, I called
 container.clear(). Reasonable enough, right? Hell, it even compiled!

 Turns out, my program completely broke at runtime. Apparently, I'd
 forgotten to implement clear() on my container class, and
 *object.clear() was being called instead*.

 I don't blame UFCS for this. It just happened to be the reason this
 compiled at all. But, what I do think is: clear is the *ABSOLUTELY MOST
 HORRIBLE NAME EVER* for a function that actually finalizes and zeroes an
 object. Did it not seem obvious to call it, I don't know, *finalize*?
 And even ignoring the naming, having a symbol called clear in the
 'global' namespace is absolute insanity.

 Am I the only person with this opinion?

 Why is UFCS involved here ?

Since the clear method didn't exist on the type, the call was mapped to 
the clear function in the global scope. This is UFCS.

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org

deadalnix <deadalnix gmail.com> writes:

Le 25/05/2012 15:21, Alex Rønne Petersen a écrit :
 On 25-05-2012 15:17, deadalnix wrote:
 Le 25/05/2012 15:04, Alex Rønne Petersen a écrit :
 So I was writing a container class and in some test code, I called
 container.clear(). Reasonable enough, right? Hell, it even compiled!

 Turns out, my program completely broke at runtime. Apparently, I'd
 forgotten to implement clear() on my container class, and
 *object.clear() was being called instead*.

 I don't blame UFCS for this. It just happened to be the reason this
 compiled at all. But, what I do think is: clear is the *ABSOLUTELY MOST
 HORRIBLE NAME EVER* for a function that actually finalizes and zeroes an
 object. Did it not seem obvious to call it, I don't know, *finalize*?
 And even ignoring the naming, having a symbol called clear in the
 'global' namespace is absolute insanity.

 Am I the only person with this opinion?

 Why is UFCS involved here ?

 Since the clear method didn't exist on the type, the call was mapped to
 the clear function in the global scope. This is UFCS.

OK, I get it ! Weird side effect :D

BTW, where is the documentation about clear and emplace ? I can't find 
it on dlang.org .

=?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <alex lycus.org> writes:

On 25-05-2012 16:50, deadalnix wrote:
 Le 25/05/2012 15:21, Alex Rønne Petersen a écrit :
 On 25-05-2012 15:17, deadalnix wrote:
 Le 25/05/2012 15:04, Alex Rønne Petersen a écrit :
 So I was writing a container class and in some test code, I called
 container.clear(). Reasonable enough, right? Hell, it even compiled!

 Turns out, my program completely broke at runtime. Apparently, I'd
 forgotten to implement clear() on my container class, and
 *object.clear() was being called instead*.

 I don't blame UFCS for this. It just happened to be the reason this
 compiled at all. But, what I do think is: clear is the *ABSOLUTELY MOST
 HORRIBLE NAME EVER* for a function that actually finalizes and
 zeroes an
 object. Did it not seem obvious to call it, I don't know, *finalize*?
 And even ignoring the naming, having a symbol called clear in the
 'global' namespace is absolute insanity.

 Am I the only person with this opinion?

 Why is UFCS involved here ?

 Since the clear method didn't exist on the type, the call was mapped to
 the clear function in the global scope. This is UFCS.

 OK, I get it ! Weird side effect :D

 BTW, where is the documentation about clear and emplace ? I can't find
 it on dlang.org .

I think clear() is basically entirely undocumented still.

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Fri, 25 May 2012 10:52:15 -0400, Alex R=C3=B8nne Petersen <alex lycus=
.org>  =

wrote:

 On 25-05-2012 16:50, deadalnix wrote:
 Le 25/05/2012 15:21, Alex R=C3=B8nne Petersen a =C3=A9crit :
 On 25-05-2012 15:17, deadalnix wrote:
 Le 25/05/2012 15:04, Alex R=C3=B8nne Petersen a =C3=A9crit :
 So I was writing a container class and in some test code, I called=





 container.clear(). Reasonable enough, right? Hell, it even compile=





d!
 Turns out, my program completely broke at runtime. Apparently, I'd=





 forgotten to implement clear() on my container class, and
 *object.clear() was being called instead*.

 I don't blame UFCS for this. It just happened to be the reason thi=





s
 compiled at all. But, what I do think is: clear is the *ABSOLUTELY=





  =

 MOST
 HORRIBLE NAME EVER* for a function that actually finalizes and
 zeroes an
 object. Did it not seem obvious to call it, I don't know, *finaliz=





e*?
 And even ignoring the naming, having a symbol called clear in the
 'global' namespace is absolute insanity.

 Am I the only person with this opinion?

 Why is UFCS involved here ?

 Since the clear method didn't exist on the type, the call was mapped=



 to
 the clear function in the global scope. This is UFCS.

 OK, I get it ! Weird side effect :D

 BTW, where is the documentation about clear and emplace ? I can't fin=


d
 it on dlang.org .

 I think clear() is basically entirely undocumented still.

Wow, you're right, it's not documented.  That should be fixed!

-Steve

=?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:

On 25-05-2012 16:56, Steven Schveighoffer wrote:
 On Fri, 25 May 2012 10:52:15 -0400, Alex Rønne Petersen
 <alex lycus..org> wrote:

 On 25-05-2012 16:50, deadalnix wrote:
 Le 25/05/2012 15:21, Alex Rønne Petersen a écrit :
 On 25-05-2012 15:17, deadalnix wrote:
 Le 25/05/2012 15:04, Alex Rønne Petersen a écrit :
 So I was writing a container class and in some test code, I called
 container.clear(). Reasonable enough, right? Hell, it even compiled!

 Turns out, my program completely broke at runtime. Apparently, I'd
 forgotten to implement clear() on my container class, and
 *object.clear() was being called instead*.

 I don't blame UFCS for this. It just happened to be the reason this
 compiled at all. But, what I do think is: clear is the *ABSOLUTELY
 MOST
 HORRIBLE NAME EVER* for a function that actually finalizes and
 zeroes an
 object. Did it not seem obvious to call it, I don't know, *finalize*?
 And even ignoring the naming, having a symbol called clear in the
 'global' namespace is absolute insanity.

 Am I the only person with this opinion?

 Why is UFCS involved here ?

 Since the clear method didn't exist on the type, the call was mapped to
 the clear function in the global scope. This is UFCS.

 OK, I get it ! Weird side effect :D

 BTW, where is the documentation about clear and emplace ? I can't find
 it on dlang.org .

 I think clear() is basically entirely undocumented still.

 Wow, you're right, it's not documented. That should be fixed!

 -Steve

We actually have tons of documentation that still encourages using delete...

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org

=?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:

On 25-05-2012 16:56, Steven Schveighoffer wrote:
 On Fri, 25 May 2012 10:52:15 -0400, Alex Rønne Petersen
 <alex lycus..org> wrote:

 On 25-05-2012 16:50, deadalnix wrote:
 Le 25/05/2012 15:21, Alex Rønne Petersen a écrit :
 On 25-05-2012 15:17, deadalnix wrote:
 Le 25/05/2012 15:04, Alex Rønne Petersen a écrit :
 So I was writing a container class and in some test code, I called
 container.clear(). Reasonable enough, right? Hell, it even compiled!

 Turns out, my program completely broke at runtime. Apparently, I'd
 forgotten to implement clear() on my container class, and
 *object.clear() was being called instead*.

 I don't blame UFCS for this. It just happened to be the reason this
 compiled at all. But, what I do think is: clear is the *ABSOLUTELY
 MOST
 HORRIBLE NAME EVER* for a function that actually finalizes and
 zeroes an
 object. Did it not seem obvious to call it, I don't know, *finalize*?
 And even ignoring the naming, having a symbol called clear in the
 'global' namespace is absolute insanity.

 Am I the only person with this opinion?

 Why is UFCS involved here ?

 Since the clear method didn't exist on the type, the call was mapped to
 the clear function in the global scope. This is UFCS.

 OK, I get it ! Weird side effect :D

 BTW, where is the documentation about clear and emplace ? I can't find
 it on dlang.org .

 I think clear() is basically entirely undocumented still.

 Wow, you're right, it's not documented. That should be fixed!

 -Steve

Before we do, we should deprecate clear and rename it to finalize, though.

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Fri, 25 May 2012 11:03:33 -0400, Alex R=C3=B8nne 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

=?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:

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

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Fri, 25 May 2012 11:28:07 -0400, Alex R=C3=B8nne 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=C3=B8nne 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 resourc=
es  =

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

-Steve

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

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=C3=B8nne Petersen <alex lyc=

us.org>  =

 wrote:

 On 25-05-2012 17:23, Steven Schveighoffer wrote:
 On Fri, 25 May 2012 11:03:33 -0400, Alex R=C3=B8nne 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 t=

he  =

 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

Mirko Pilger <pilger cymotec.de> writes:

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

what about "invalidate"?

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

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

"Francisco Almeida" <francisco.m.almeida gmail.com> writes:

On Friday, 25 May 2012 at 18:22:08 UTC, Andrei Alexandrescu wrote:
 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

I vote for destroy().
It seems to be a popular choice, and it isn't ambiguous in any 
way.
Are there any classes/structs using destroy() methods in Phobos?

Francisco

=?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:

On 26-05-2012 10:48, Francisco Almeida wrote:
 On Friday, 25 May 2012 at 18:22:08 UTC, Andrei Alexandrescu wrote:
 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

 I vote for destroy().
 It seems to be a popular choice, and it isn't ambiguous in any way.
 Are there any classes/structs using destroy() methods in Phobos?

 Francisco

It doesn't actually matter. It wouldn't be ambiguous. UFCS prefers the 
method on a class/struct over a free function.

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org

"David Nadlinger" <see klickverbot.at> writes:

On Saturday, 26 May 2012 at 08:52:06 UTC, Alex Rønne Petersen 
wrote:
 On 26-05-2012 10:48, Francisco Almeida wrote:
 I vote for destroy().
 It seems to be a popular choice, and it isn't ambiguous in any 
 way.
 Are there any classes/structs using destroy() methods in 
 Phobos?

 Francisco

 It doesn't actually matter. It wouldn't be ambiguous. UFCS 
 prefers the method on a class/struct over a free function.

It wouldn't break existing types, yes, but would probably cause 
confusion similar to clear() right now if the name was already in 
(widespread) use.

David

sclytrack <sclytrack iq87.fr> writes:

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

Brad Anderson <eco gnuk.net> writes:

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=F8nne 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=F8nne 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().

"John Chapman" <johnch_atms hotmail.com> writes:

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().

"Mehrdad" <wfunction hotmail.com> writes:

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

Jonathan M Davis <jmdavisProg gmx.com> writes:

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

"Mehrdad" <wfunction hotmail.com> writes:

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

Jonathan M Davis <jmdavisProg gmx.com> writes:

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

"Mehrdad" <wfunction hotmail.com> writes:

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?

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Saturday, May 26, 2012 04:34:30 Mehrdad wrote:
 Okay, thanks for the explanation.
 
 So basically, clear() just calls __dtor(), and then zeros out the
 vtable?

Yes, though it calls rt_finalize on classes rather than dtor directly, so that 
may do some extra stuff beyond strictly calling __dtor and zeroing 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?

Normally when an object is destroyed, all of its member variables' destructors 
would be called as well (at least for member variables which are structs or 
arrays of structs - member variables which are classes aren't finalized). But 
the destructor itself doesn't call all of the member variables' destructors, 
so calling __dtor doesn't call them. You have to do something else to get the 
member variables destroyed as well (something with typeid I think, but I don't 
remember the details).

- Jonathan M Davis

"Mehrdad" <wfunction hotmail.com> writes:

On Saturday, 26 May 2012 at 02:46:57 UTC, Jonathan M Davis wrote:
 Normally when an object is destroyed, all of its member 
 variables' destructors would be called as well (at least for 
 member variables which are structs or arrays of structs - 
 member variables which are classes aren't finalized)



Ahh, that was what confused me, thanks... I thought you were 
referring to member /Object/s.

"Mehrdad" <wfunction hotmail.com> writes:

Why not just call it 'destroy()'?

"jerro" <a a.com> writes:

On Saturday, 26 May 2012 at 03:21:31 UTC, Mehrdad wrote:
 Why not just call it 'destroy()'?

+1

sclytrack <sclytrack iq87.fr> writes:

On 05/26/2012 06:58 AM, jerro wrote:
 On Saturday, 26 May 2012 at 03:21:31 UTC, Mehrdad wrote:
 Why not just call it 'destroy()'?

 +1

+1

And as a bonus all the Delphi dudes will feel right at home.

"RivenTheMage" <riven-mage id.ru> writes:

On Saturday, 26 May 2012 at 06:06:08 UTC, sclytrack wrote:
 On 05/26/2012 06:58 AM, jerro wrote:
 On Saturday, 26 May 2012 at 03:21:31 UTC, Mehrdad wrote:
 Why not just call it 'destroy()'?

 +1

 +1

+1

"Era Scarecrow" <rtcvb32 yahoo.com> writes:

On Saturday, 26 May 2012 at 08:38:10 UTC, RivenTheMage wrote:
 On Saturday, 26 May 2012 at 06:06:08 UTC, sclytrack wrote:
 On 05/26/2012 06:58 AM, jerro wrote:
 On Saturday, 26 May 2012 at 03:21:31 UTC, Mehrdad wrote:
 Why not just call it 'destroy()'?

 +1

 +1

 +1

+1

  I'll agree, destroy has no hidden meanings and is easy to 
remember. If 'clear' becomes free, it can be used in other 
things, say a graphics program that clears a editing window.

  I also liked recycle and zero. Dump should probably not be used, 
as having used linux dump to me means you'd want to dump the 
object's data out to the screen or to a file for analysis.

Jacob Carlborg <doob me.com> writes:

On 2012-05-26 03:38, Jonathan M Davis wrote:

 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

Why can't "delete" do what "clear" does. Backwards compatibility?

-- 
/Jacob Carlborg

Michel Fortin <michel.fortin michelf.com> writes:

On 2012-05-26 12:00:15 +0000, Jacob Carlborg <doob me.com> said:

 On 2012-05-26 03:38, Jonathan M Davis wrote:
 
 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

 
 Why can't "delete" do what "clear" does. Backwards compatibility?

That'd be my preferred solution too. I think it makes a lot of sense. 
Clear does almost the same thing as delete, except that currently 
delete means memory can be reused immediately, which is not safe. If 
the only difference is that one is safe and the other is not, and if 
we're going to deprecate and then remove delete because it's not safe, 
wouldn't it make more sense to simply make 'delete' memory-safe by 
giving it the semantics of clear()?

By the way, clear() as "clear" would have made more sense if it was 
effectively destructing then reconstructing the object in place, making 
it a suitable default implementation of the container-kind clear(). But 
for what it does right now, it's *clearly* misleading.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Saturday, May 26, 2012 14:00:15 Jacob Carlborg wrote:
 On 2012-05-26 03:38, Jonathan M Davis wrote:
 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

 
 Why can't "delete" do what "clear" does. Backwards compatibility?

I would think that that would be a bad idea, because it wouldn't be doing what 
delete does in C++ at all and would be really confusing to a lot of people. It 
would probably work without them realizing what was going on (since it's 
stupid to do anything with a deleted object other than assign it a new value, 
which would work with clear), but it would end up with very different behavior 
memory-wise, causing unexpected behavior.

Another problem is that we're trying to discourage using stuff like clear 
unless you actually need to and know what you're doing, whereas delete is used 
all the time in C++, because it doesn't _have_ a GC built in. So, having clear 
as a language construct rather than a function is arguably a bad idea, because 
it elevates it to something more normal. If it's delete, a lot of people will 
just use it without learning what's really going on, whereas they'll have to 
actually learn about clear to use it.

Also, it  would have a negative effect on ported code to change clear to 
delete. If delete is illegal, then the compiler will catch it when you forget 
to remove it from ported code, whereas if it just does what clear does, you 
could end up with deletes left in when you didn't intend to, but now they have 
different semantics.

- Jonathan M Davis

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 5/25/12 7:30 PM, 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...

delete also deallocates.

Andrei

Dmitry Olshansky <dmitry.olsh gmail.com> writes:

On 25.05.2012 23:34, sclytrack wrote:

 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 like wipe though obliterate is so much clearer ... :)

-- 
Dmitry Olshansky

"Simen Kjaeraas" <simen.kjaras gmail.com> writes:

On Sat, 26 May 2012 08:49:19 +0200, Dmitry Olshansky  
<dmitry.olsh gmail.com> wrote:

 On 25.05.2012 23:34, sclytrack wrote:

 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 like wipe though obliterate is so much clearer ... :)

I also love obliterate. And annihilate. But I would be more than happy with
destroy.

"Joshua Niehus" <jm.niehus gmail.com> writes:

 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

disembowel?

Ary Manzana <ary esperanto.org.ar> writes:

On 5/25/12 22:42 , Steven Schveighoffer wrote:
 Finalize isn't right, and neither is dispose...

In Java it's finalize:

http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/Object.html#finalize()

In Ruby it's define_finalizer:

http://www.ruby-doc.org/core-1.9.3/ObjectSpace.html#method-c-define_finalizer

Why not calling finalize then? A bonus is that programmers coming from 
those languages will find the name more intuitive.

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Sat, 26 May 2012 02:31:46 -0400, Ary Manzana <ary esperanto.org.ar>  
wrote:

 On 5/25/12 22:42 , Steven Schveighoffer wrote:
 Finalize isn't right, and neither is dispose...

 In Java it's finalize:

 http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/Object.html#finalize()

No, this is the GC finalizer.  This is equivalent to D's class destructor.

We need a function name that denotes *deterministic* destruction.

 In Ruby it's define_finalizer:

 http://www.ruby-doc.org/core-1.9.3/ObjectSpace.html#method-c-define_finalizer

I don't know enough about Ruby to comment, but is this called by the GC?   
It seems like it is.

 Why not calling finalize then? A bonus is that programmers coming from  
 those languages will find the name more intuitive.

Actually, they will find it confusing, since it doesn't do the same thing.

-Steve

=?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:

On 25-05-2012 17:37, Steven Schveighoffer 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

 -Steve

But if clear() *does* run the finalizer *now*, then finalize would be a 
better name, no?

I'm all for the dispose model, but then we need a way to suppress 
finalizers too.

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Fri, 25 May 2012 11:42:57 -0400, Alex R=C3=B8nne Petersen <alex lycus=
.org>  =

wrote:

 On 25-05-2012 17:37, Steven Schveighoffer wrote:
 On Fri, 25 May 2012 11:28:07 -0400, Alex R=C3=B8nne 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=C3=B8nne 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

 -Steve

 But if clear() *does* run the finalizer *now*, then finalize would be =

a  =

 better name, no?

 I'm all for the dispose model, but then we need a way to suppress  =

 finalizers too.

This is what I think clear (or function to be named later) should do:

if(obj.dispose())
   rt_finalize(obj);
else
   rt_suppressFinalize(obj);

That way you can write code like this:

class File
{
    bool dispose()
    {
       flush();
       return true;
    }

    ~this()
    {
       close(handle);
    }
}

and you don't have to repeat the finalize code inside the dispose routin=
e  =

if it's a normal part of deterministic destruction.

-Steve

=?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:

On 25-05-2012 17:59, Steven Schveighoffer wrote:
 On Fri, 25 May 2012 11:42:57 -0400, Alex Rønne Petersen
 <alex lycus..org> wrote:

 On 25-05-2012 17:37, Steven Schveighoffer 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

 -Steve

 But if clear() *does* run the finalizer *now*, then finalize would be
 a better name, no?

 I'm all for the dispose model, but then we need a way to suppress
 finalizers too.

 This is what I think clear (or function to be named later) should do:

 if(obj.dispose())
 rt_finalize(obj);
 else
 rt_suppressFinalize(obj);

 That way you can write code like this:

 class File
 {
 bool dispose()
 {
 flush();
 return true;
 }

 ~this()
 {
 close(handle);
 }
 }

 and you don't have to repeat the finalize code inside the dispose
 routine if it's a normal part of deterministic destruction.

 -Steve

Sounds good to me.

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org

=?ISO-8859-1?Q?S=F6nke_Ludwig?= <sludwig outerproduct.org> writes:

Am 25.05.2012 15:04, schrieb Alex Rønne Petersen:
 So I was writing a container class and in some test code, I called
 container.clear(). Reasonable enough, right? Hell, it even compiled!

 Turns out, my program completely broke at runtime. Apparently, I'd
 forgotten to implement clear() on my container class, and
 *object.clear() was being called instead*.

 I don't blame UFCS for this. It just happened to be the reason this
 compiled at all. But, what I do think is: clear is the *ABSOLUTELY MOST
 HORRIBLE NAME EVER* for a function that actually finalizes and zeroes an
 object. Did it not seem obvious to call it, I don't know, *finalize*?
 And even ignoring the naming, having a symbol called clear in the
 'global' namespace is absolute insanity.

 Am I the only person with this opinion?

I completely agree! Had the same situation before...

Also I hate that UFCS is doing the same thing that properties did in the 
beginning and have no way to enforce a specific usage. I strongly 
believe that it is a (often important) decision of the library architect 
if a function is to be called normally or as member function style.

Artur Skawina <art.08.09 gmail.com> writes:

On 05/25/12 18:11, Sönke Ludwig wrote:
 Am 25.05.2012 15:04, schrieb Alex Rønne Petersen:
 So I was writing a container class and in some test code, I called
 container.clear(). Reasonable enough, right? Hell, it even compiled!

 Turns out, my program completely broke at runtime. Apparently, I'd
 forgotten to implement clear() on my container class, and
 *object.clear() was being called instead*.

 I don't blame UFCS for this. It just happened to be the reason this
 compiled at all. But, what I do think is: clear is the *ABSOLUTELY MOST
 HORRIBLE NAME EVER* for a function that actually finalizes and zeroes an
 object. Did it not seem obvious to call it, I don't know, *finalize*?
 And even ignoring the naming, having a symbol called clear in the
 'global' namespace is absolute insanity.

 Am I the only person with this opinion?

 
 I completely agree! Had the same situation before...
 
 Also I hate that UFCS is doing the same thing that properties did in the
beginning and have no way to enforce a specific usage. I strongly believe that
it is a (often important) decision of the library architect if a function is to
be called normally or as member function style.
 

 method ?

artur

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Friday, May 25, 2012 15:04:16 Alex R=C3=B8nne Petersen wrote:
 So I was writing a container class and in some test code, I called
 container.clear(). Reasonable enough, right? Hell, it even compiled!
=20
 Turns out, my program completely broke at runtime. Apparently, I'd
 forgotten to implement clear() on my container class, and
 *object.clear() was being called instead*.
=20
 I don't blame UFCS for this. It just happened to be the reason this
 compiled at all. But, what I do think is: clear is the *ABSOLUTELY MO=

ST
 HORRIBLE NAME EVER* for a function that actually finalizes and zeroes=

 an
 object. Did it not seem obvious to call it, I don't know, *finalize*?=

 And even ignoring the naming, having a symbol called clear in the
 'global' namespace is absolute insanity.
=20
 Am I the only person with this opinion?

https://github.com/D-Programming-Language/druntime/pull/231

=?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:

On 30-05-2012 08:43, Jonathan M Davis wrote:
 On Friday, May 25, 2012 15:04:16 Alex Rønne Petersen wrote:
 So I was writing a container class and in some test code, I called
 container.clear(). Reasonable enough, right? Hell, it even compiled!

 Turns out, my program completely broke at runtime. Apparently, I'd
 forgotten to implement clear() on my container class, and
 *object.clear() was being called instead*.

 I don't blame UFCS for this. It just happened to be the reason this
 compiled at all. But, what I do think is: clear is the *ABSOLUTELY MOST
 HORRIBLE NAME EVER* for a function that actually finalizes and zeroes an
 object. Did it not seem obvious to call it, I don't know, *finalize*?
 And even ignoring the naming, having a symbol called clear in the
 'global' namespace is absolute insanity.

 Am I the only person with this opinion?

 https://github.com/D-Programming-Language/druntime/pull/231

Thanks!

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org