title: When shouldn't I implement IDisposable?
body: <p>Firstly, sorry if this is considered a duplicate - I know it is a common topic, but I have looked and not found a satisfactory answer.</p>
  
  <p>There are a lot of questions asking when <strong>to</strong> use <code>IDisposable</code>, but from everything I've read, I just can't see why you wouldn't implement it in every class you make. What is there to lose? Does it have a big performance hit?</p>
  
  <p>Part of my understanding of <code>IDisposable</code> is that one of the things it does is: 
  <a href="https://stackoverflow.com/a/6448682/2487619">Dispose()ing other IDisposables owned by the object</a>. Forgive my ignorance, but does this apply only to fields/properties of the given object, or does it also extend to objects created within its methods too?</p>
  
  <p>For instance, if a <code>Font</code> was created inside a method within a class that implements <code>IDisposable</code>, but that <code>Font</code> wasn't initialised with a <code>using</code> block, or <code>.Dispose()</code>d explicitly at the end of the method; would it be disposed when its <code>IDisposable</code> parent/class was GCd/disposed? Or otherwise, would the <code>Font</code> never be disposed?</p>
  
  <p>I don't mean to digress, but if it is true that it would act as a 'catch all' like this (effectively disposing of any erroneous child <code>IDisposable</code> objects that would otherwise be left undisposed), isn't that reason alone enough to justify <strong>always</strong> implementing <code>IDisposable</code> whenever possible?</p>