I don&#39;t have a lot of experience in this field, but my guess is people want to help out the GC be more efficient in some regard. <br><br>&quot;Hey, GC! I know you take the trash out every day, but I just want to let you know that I&#39;ve cleaned up my room and there&#39;s a whole bag o&#39; dirt in here ready to be thrown out that you should know about. See ya later!&quot;<br>
<br>My assumption is that the programmer probably knows when and how he uses memory more so than the GC itself. So my thinking is some kind of hybrid approach would be a good choice between safety and performance here. But correct me if I&#39;m wrong, I&#39;m walking in the dark really..<br>
<br><div class="gmail_quote">On Tue, Aug 10, 2010 at 1:57 AM, Jonathan M Davis <span dir="ltr">&lt;<a href="mailto:jmdavisprog@gmail.com">jmdavisprog@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On Monday, August 09, 2010 16:40:23 Andrei Alexandrescu wrote:<br>
&gt; class File {<br>
&gt;      FILE * fp;<br>
&gt;      this() { fp = fopen(&quot;/tmp/temporary&quot;); }<br>
&gt;      ~this() { fclose(fp); }<br>
&gt; }<br>
&gt;<br>
&gt; The destructor does not test fp because it assumes it was opened.<br>
&gt;<br>
&gt; Interestingly enough, by TDPL the code above is in fact invalid already.<br>
&gt; TDPL mentions that an object&#39;s lifetime starts as soon as it&#39;s been<br>
&gt; branded, which is before default construction. As a direct consequence,<br>
&gt; the destructor should be able to deal with an object stamped with all<br>
&gt; init values for all fields - in this case a null fp.<br>
<br>
</div>I would take that as an argument for making clear() set the object in the state<br>
prior to the constructor call. That state is supposed to be completely valid<br>
from a memory standpoint. True, it goes against class invariants, but it would<br>
make clear() function in a manner closer to the delete that some folks are<br>
looking for. Truth be told, I&#39;d sooner argue for removing clear() entirely,<br>
forcing people to either call a specific method on the class in question to free<br>
up whatever resources that they&#39;re so interested in freeing up, or forcing them<br>
to just give up on trying to free them and let the garbage collector do its<br>
thing. But if there&#39;s enough demand for a function which destroys an object and<br>
puts it in some sort of state which won&#39;t have undefined behavior, then making<br>
clear() put the class in a pre-constructor state seems the best to me. It&#39;s at<br>
least closer to what the folks who want delete are looking for. Of course, they<br>
probably won&#39;t be entirely happy until they have the nuke() function that you<br>
mentioned earlier, but at some point you have to face the fact that you&#39;re<br>
dealing with a garbage collected langugage and let it do its thing unless you<br>
really need to manually manage memory (at which point you should manually manage<br>
memory rather than try to contort the garbage collector).<br>
<font color="#888888"><br>
- Jonathan M Davis<br>
</font></blockquote></div><br>