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

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

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

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

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/

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

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.

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.

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

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