title: Constructing/making a generic type and turning a type constraint into a struct-as-base-type constraint
body: <p>Normally we cannot constrain a type parameter <code>T</code> to deriving from a sealed type (such as a <code>struct</code> type). This would be meaningless because there is only one type which could fit, and as such there is no need for generics. So constraints like:</p>
  
  <pre><code>where T : string
  </code></pre>
  
  <p>or:</p>
  
  <pre><code>where T : DateTime
  </code></pre>
  
  <p>are illegal, for a very good reason.</p>
  
  <p>However, when constraining to another type parameter, this can sometimes happen when that other type parameter is "substituted" into an actual type (which happens to be sealed). Consider the class:</p>
  
  <pre><code>abstract class ExampleBase&lt;TFromType&gt;
  {
    internal abstract void M&lt;TFromMethod&gt;(TFromMethod value) where TFromMethod : TFromType;
  }
  </code></pre>
  
  <p>which is quite innocent. In the concretization:</p>
  
  <pre><code>class ExampleOne : ExampleBase&lt;string&gt;
  {
    internal override void M&lt;TFromMethod&gt;(TFromMethod strangeString)
    {
      var a = string.IsNullOrEmpty(strangeString);
      Console.WriteLine(a);
      var b = strangeString.Substring(10, 2);
      Console.WriteLine(b);
    }
  }
  </code></pre>
  
  <p>we make <code>TFromType</code> equal to <code>string</code>. This could be meaningful wrt. other members than <code>M&lt;&gt;</code>. But <code>M&lt;&gt;</code> itself can still be used: The code:</p>
  
  <pre><code>  var e1 = new ExampleOne();
    e1.M("abcdefghijklmnopqrstuvwxyz");
  </code></pre>
  
  <p>will run and write:</p>
  
  <pre>False
  kl</pre>
  
  <p>to the console. So the constraint essentially became <code>where TFromMethod : string</code>, but things were still fine.</p>
  
  <p>This question is about what happens if <code>TFromType</code> is a value type. So this time we do:</p>
  
  <pre><code>class ExampleTwo : ExampleBase&lt;DateTime&gt;
  {
    internal override void M&lt;TFromMethod&gt;(TFromMethod strangeDate)
    {
      // var c = DateTime.SpecifyKind(strangeDate, DateTimeKind.Utc);  // will not compile
      // var d = strangeDate.AddDays(66.5);  // will not compile
  
      var e = string.Format(CultureInfo.InvariantCulture, "{0:D}", strangeDate);  // OK, through boxing
      Console.WriteLine(e);
      var f = object.ReferenceEquals(strangeDate, strangeDate);
      Console.WriteLine("Was 'strangeDate' a box? " + f);
    }
  }
  </code></pre>
  
  <p><strong>So why are the calls from the <code>c</code> and <code>d</code> declarations not allowed?</strong> After all <code>strangeDate</code> has compile-time type <code>TFromMethod</code> which is constrained to be a <code>DateTime</code>. So surely <code>strangeDate</code> is implicitly a <code>DateTime</code>? After all, this worked with <code>string</code> (<code>class ExampleOne</code> above).</p>
  
  <p>I would prefer an answer which referred to the relevant place in the official C# Language Specification.</p>
  
  <p>Note that when trying to add <code>d</code>, typing <code>strangeDate.Ad</code>... makes IntelliSense (Visual Studio's autocompleter) come up with a list of all accessible instance members of <code>DateTime</code>, so clearly IntelliSense thinks the call in <code>d</code> should be legal!</p>
  
  <p>Of course, after <code>c</code> and <code>d</code> have been commented out, we can use <code>ExampleTwo</code> (with <code>e</code> and <code>f</code>), and the code:</p>
  
  <pre><code>  var e2 = new ExampleTwo();
    e2.M(new DateTime(2015, 2, 13));
  </code></pre>
  
  <p>runs and writes out:</p>
  
  <pre>Friday, 13 February 2015
  Was 'strangeDate' a box? False</pre>