On Apr 19, 11 01:25, Graham Fawcett wrote:
> On Mon, 18 Apr 2011 11:38:56 -0400, Steven Schveighoffer wrote:
>
>> On Mon, 18 Apr 2011 11:21:46 -0400, Graham Fawcett<fawcett@uwindsor.ca>
>> wrote:
>>
[snip]
>> The recommended alternative to destruction is to use clear, since it
>> runs the appropriate finalizers, plus sets it to null.
>
> Thanks for that. The documentation for std.array.clear() is rather terse
> ("clears the managed array"), so your explanation is very helpful.
>
> Best,
> Graham
>

By 'clear' he means the global function 'clear' in object.di (It seems not documented on the digitalmars website), not std.array.Appender.clear().

https://github.com/D-Programming-Language/druntime/blob/master/import/object.di#L437

On Mon, 18 Apr 2011 15:17:11 -0400, KennyTM~ <kennytm@gmail.com> wrote:

> On Apr 19, 11 01:25, Graham Fawcett wrote:
>> On Mon, 18 Apr 2011 11:38:56 -0400, Steven Schveighoffer wrote:
>>
>>> On Mon, 18 Apr 2011 11:21:46 -0400, Graham Fawcett<fawcett@uwindsor.ca>
>>> wrote:
>>>
> [snip]
>>> The recommended alternative to destruction is to use clear, since it
>>> runs the appropriate finalizers, plus sets it to null.
>>
>> Thanks for that. The documentation for std.array.clear() is rather terse
>> ("clears the managed array"), so your explanation is very helpful.
>>
>> Best,
>> Graham
>>
>
> By 'clear' he means the global function 'clear' in object.di (It seems not documented on the digitalmars website), not std.array.Appender.clear().
>
> https://github.com/D-Programming-Language/druntime/blob/master/import/object.di#L437

That is a large omission! clear should be documented.

I made a bugzilla report: http://d.puremagic.com/issues/show_bug.cgi?id=5855

-Steve

Steven Schveighoffer wrote:
> And one other note -- delete will eventually be deprecated.  In order to free memory, you must use clear and GC.free.

> -Steve

Well, why? It seems like a bad decision to me.

On Tue, 19 Apr 2011 14:04:38 -0400, Timon Gehr <timon.gehr@gmx.ch> wrote:

> Steven Schveighoffer wrote:
>> And one other note -- delete will eventually be deprecated.  In order to
>> free memory, you must use clear and GC.free.
>
>> -Steve
>
> Well, why? It seems like a bad decision to me.

I'm neutral on the subject, you'd have to ask Andrei.  I rarely use delete anyways.

-Steve

On 4/19/11 1:04 PM, Timon Gehr wrote:
> Steven Schveighoffer wrote:
>> And one other note -- delete will eventually be deprecated.  In order to
>> free memory, you must use clear and GC.free.
>
>> -Steve
>
> Well, why? It seems like a bad decision to me.

The feature is not going away, just the keyword.

"delete" is a gratuitous carryover from C++, which had to invent it because the need for manual object disposal predated the introduction of templates.

D stays a systems programming language but also has a safe subset and generally offers better safety guarantees than C++. It is excessive to allocate a keyword to a feature that's fundamentally unsafe, particularly since the underlying feature offers considerably fewer guarantees than its C++ counterpart. (Some GCs are unable to implement "delete" meaningfully.)

Manual memory disposal for the GC heap will be implemented as a template function with semantics defined by the GC implementation.



Andrei

Andrei:

> (Some GCs are unable to implement "delete" meaningfully.)
> 
> Manual memory disposal for the GC heap will be implemented as a template function with semantics defined by the GC implementation.

Now the function(s) that replace "delete" are meant to be hints for the GC. In a system language that uses a GC you probably enjoy some different kinds of GC hints (as in CLisp GC).

Bye,
bearophile

== Quote from Andrei Alexandrescu (SeeWebsiteForEmail@erdani.org)'s article
> On 4/19/11 1:04 PM, Timon Gehr wrote:
> > Steven Schveighoffer wrote:
> >> And one other note -- delete will eventually be deprecated.  In order to free memory, you must use clear and GC.free.
> >
> >> -Steve
> >
> > Well, why? It seems like a bad decision to me.
> The feature is not going away, just the keyword.
> "delete" is a gratuitous carryover from C++, which had to invent it
> because the need for manual object disposal predated the introduction of
> templates.
> D stays a systems programming language but also has a safe subset and
> generally offers better safety guarantees than C++. It is excessive to
> allocate a keyword to a feature that's fundamentally unsafe,
> particularly since the underlying feature offers considerably fewer
> guarantees than its C++ counterpart. (Some GCs are unable to implement
> "delete" meaningfully.)
> Manual memory disposal for the GC heap will be implemented as a template
> function with semantics defined by the GC implementation.
> Andrei

Well, I don't understand internal architecture at all, but from user's point of view it would be good keep some simple and nice way to remove object. I like if I can have things under control - if I want.

lenochware Wrote:

> Well, I don't understand internal architecture at all, but from user's point of view it would be good keep some simple and nice way to remove object. I like if I can have things under control - if I want.

clear(myObjectThatMustGo);