www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - clear() and UFCS

reply =?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
May 25 2012
next sibling parent reply 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
May 25 2012
parent reply 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
May 25 2012
parent 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.
May 25 2012
prev sibling next sibling parent reply 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 ?
May 25 2012
next sibling parent reply =?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
May 25 2012
parent reply 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 .
May 25 2012
parent reply =?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
May 25 2012
next sibling parent =?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
May 25 2012
prev sibling parent reply =?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
May 25 2012
parent reply =?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
May 25 2012
next sibling parent reply =?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
May 25 2012
parent =?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
May 25 2012
prev sibling next sibling parent reply 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"?
May 25 2012
parent reply 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
May 25 2012
parent =?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
May 26 2012
prev sibling next sibling parent reply 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
May 25 2012
next sibling parent 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


One for the Doctor Who fans among us: exterminate().

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

delete also deallocates. Andrei
May 25 2012
prev sibling next sibling parent 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

-- Dmitry Olshansky
May 25 2012
prev sibling parent 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/
May 26 2012
prev sibling parent 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.
May 25 2012
prev sibling next sibling parent "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=





 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=





 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=





 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=



 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=


 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
May 25 2012
prev sibling next sibling parent "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
May 25 2012
prev sibling next sibling parent "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
May 25 2012
prev sibling next sibling parent "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=

 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=

 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
May 25 2012
prev sibling next sibling parent "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 =


 handle

 -Steve

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

 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
May 25 2012
prev sibling next sibling parent Brad Anderson <eco gnuk.net> writes:
--bcaec52be5f1aba31c04c0e20ac2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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

--bcaec52be5f1aba31c04c0e20ac2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, May 25, 2012 at 1:34 PM, sclytrack <span dir=3D"ltr">&lt;<a href=3D= "mailto:sclytrack iq87.fr" target=3D"_blank">sclytrack iq87.fr</a>&gt;</spa= n> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" s= tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"HOEnZb"><div class=3D"h5">On 05/25/2012 05:42 PM, Steven Schv= eighoffer wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On Fri, 25 May 2012 11:37:52 -0400, Steven Schveighoffer<br> &lt;<a href=3D"mailto:schveiguy yahoo.com" target=3D"_blank">schveiguy yaho= o.com</a>&gt; wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On Fri, 25 May 2012 11:28:07 -0400, Alex R=F8nne Petersen<br> &lt;<a href=3D"mailto:alex lycus.org" target=3D"_blank">alex lycus.org</a>&= gt; wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On <a href=3D"tel:25-05-2012%2017" value=3D"+12505201217" target=3D"_blank"=
25-05-2012 17</a>:23, Steven Schveighoffer wrote:<br>

x #ccc solid;padding-left:1ex"> On Fri, 25 May 2012 11:03:33 -0400, Alex R=F8nne Petersen<br> &lt;alex lycus..org&gt; wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On <a href=3D"tel:25-05-2012%2016" value=3D"+12505201216" target=3D"_blank"=
25-05-2012 16</a>:56, Steven Schveighoffer wrote:<br>

x #ccc solid;padding-left:1ex"> <br> Wow, you&#39;re right, it&#39;s not documented. That should be fixed!<br> </blockquote> <br> Before we do, we should deprecate clear and rename it to finalize,<br> though.<br> </blockquote> <br> I don&#39;t like finalize because it&#39;s not a finalizer.<br> <br> I think we should mimic other languages that have a finalizer and a<br> deterministic dispose function.<br> <br> -Steve<br> </blockquote> <br> But it calls rt_finalize...?<br> </blockquote> <br> Yeah, because non-deterministic destruction is part of deterministic<br> destruction.<br> <br> finalize -&gt; destroy non-gc resources<br> dispose -&gt; 1. do deterministic destruction involving possible GC<br> resources 2. call finalize.<br> <br> e.g. a buffered file:<br> <br> finalize -&gt; close the file handle<br> dispose -&gt; flush the GC allocated buffer into the handle, then close<br> the handle<br> </blockquote> <br> I take it back, dispose is no good. That should be the name of the<br> deterministic destructor in the object.<br> <br> Now I don&#39;t have a good name. Finalize isn&#39;t right, and neither is<= br> dispose...<br> <br> -Steve<br> </blockquote> <br></div></div> blank, destroy, trash, dump, zero, bleach, cleanup,<br> sanitize, burn, nuke, eject, jetisson, discard,<br> landfill, waste, litter, debris, recycle, obliterate,<br> annihilate, eradicate, expunge, finish, ravage, wipe,<br> zap, abolish, decimate, demolish, massacre, murder,<br> ruin, slaughter, quash, scrub, splat<br> <br> <br> </blockquote></div><br><div>I&#39;m partial to defenestrate().</div> --bcaec52be5f1aba31c04c0e20ac2--
May 25 2012
prev sibling next sibling parent reply "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


One for the Doctor Who fans among us: exterminate().
May 25 2012
parent 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
May 26 2012
prev sibling next sibling parent "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


One for the Doctor Who fans among us: exterminate().

or we could just, uh, bring back delete...
May 25 2012
prev sibling next sibling parent "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?
May 25 2012
prev sibling next sibling parent "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
May 26 2012
prev sibling next sibling parent "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
May 26 2012
prev sibling next sibling parent "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 also love obliterate. And annihilate. But I would be more than happy with destroy.
May 29 2012
prev sibling parent "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
May 30 2012
prev sibling next sibling parent reply =?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.
May 25 2012
parent 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
May 25 2012
prev sibling next sibling parent 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
May 25 2012
prev sibling next sibling parent "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.
May 25 2012
prev sibling next sibling parent reply 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
May 25 2012
parent 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.
May 25 2012
prev sibling next sibling parent "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?
May 25 2012
prev sibling next sibling parent 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
May 25 2012
prev sibling next sibling parent "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.
May 25 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
Why not just call it 'destroy()'?
May 25 2012
prev sibling next sibling parent "jerro" <a a.com> writes:
On Saturday, 26 May 2012 at 03:21:31 UTC, Mehrdad wrote:
 Why not just call it 'destroy()'?

+1
May 25 2012
prev sibling next sibling parent "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
May 26 2012
prev sibling next sibling parent 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
May 26 2012
prev sibling next sibling parent "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.
May 26 2012
prev sibling parent reply 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=

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

 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
May 29 2012
parent =?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
May 30 2012