title: How does "Contract.Requires<T>" behave without ccrewrite? Does this differ from "Requires"?
body: <p>When <em>not</em> using ccrewrite (say the project is built by another developer without CC installed),</p>
  
  <p>Is <code>Contract.Requires&lt;T&gt;(cond)</code> silently stripped or does it still result in behavior equivalent to <code>if (!cond) { throw new T() }</code>? (I don't care if it's another method call or two - but it should "always be checked".)</p>
  
  <p>I ask because <code>Contract.Requires&lt;T&gt;</code> appears to behave differently than <code>Contract.Requires</code>, but I'm not sure "how" or "when".</p>
  
  <p>The goal is to <em>replace</em> the construct on <em>public contracts</em></p>
  
  <pre><code>if (x != null) throw new ArgumentNullException();
  </code></pre>
  
  <p>with a CC-compatible version that will still throw an exception when not performing a CC rewrite during the build step.</p>
  
  <p>While the above with <code>EndContractBlock</code> does work with "Custom Parameter Validation" (ie. legacy contract mode) I would like to use "Standard Contract Requires" in the project.</p>
  
  <p>I believe there <em>may</em> be an equivalency, because in "Custom Parameter Validation" mode I am not able to use <code>Requires&lt;T&gt;</code>; if there is no equivalency to an always-required-check, insight as to why would be nice.</p>
  
  <p>I am fine losing <code>Requires</code>, <code>Ensures</code>, and leaving in the non-honored invariant contract methods and interface contracts when CC rewriting is not done as I value them for the static analysis - but I need these always-there boundary checks to argue for keeping CC.</p>