title: Is there any benefit to this switch / pattern matching idea?
body: <p>I've been looking at F# recently, and while I'm not likely to leap the fence any time soon, it definitely highlights some areas where C# (or library support) could make life easier.</p>
  
  <p>In particular, I'm thinking about the pattern matching capability of F#, which allows a very rich syntax - much more expressive than the current switch/conditional C# equivalents. I won't try to give a direct example (my F# isn't up to it), but in short it allows:</p>
  
  <ul>
  <li>match by type (with full-coverage checking for discriminated unions) [note this also infers the type for the bound variable, giving member access etc]</li>
  <li>match by predicate</li>
  <li>combinations of the above (and possibly some other scenarios I'm not aware of)</li>
  </ul>
  
  <p>While it would be lovely for C# to eventually borrow [ahem] some of this richness, in the interim I've been looking at what can be done at runtime - for example, it is fairly easy to knock together some objects to allow:</p>
  
  <pre><code>var getRentPrice = new Switch&lt;Vehicle, int&gt;()
          .Case&lt;Motorcycle&gt;(bike =&gt; 100 + bike.Cylinders * 10) // "bike" here is typed as Motorcycle
          .Case&lt;Bicycle&gt;(30) // returns a constant
          .Case&lt;Car&gt;(car =&gt; car.EngineType == EngineType.Diesel, car =&gt; 220 + car.Doors * 20)
          .Case&lt;Car&gt;(car =&gt; car.EngineType == EngineType.Gasoline, car =&gt; 200 + car.Doors * 20)
          .ElseThrow(); // or could use a Default(...) terminator
  </code></pre>
  
  <p>where getRentPrice is a Func&lt;Vehicle,int&gt;.</p>
  
  <p>[note - maybe Switch/Case here is the wrong terms... but it shows the idea]</p>
  
  <p>To me, this is a lot clearer than the equivalent using repeated if/else, or a composite ternary conditional (which gets very messy for non-trivial expressions - brackets galore). It also avoids a <em>lot</em> of casting, and allows for simple extension (either directly or via extension methods) to more-specific matches, for example an InRange(...) match comparable to the VB Select...Case "x To y" usage.</p>
  
  <p><strong>I'm just trying to gauge if people think there is much benefit from constructs like the above (in the absence of language support)?</strong></p>
  
  <p>Note additionally that I've been playing with 3 variants of the above:</p>
  
  <ul>
  <li>a Func&lt;TSource,TValue&gt; version for evaluation - comparable to composite ternary conditional statements</li>
  <li>an Action&lt;TSource&gt; version - comparable to if/else if/else if/else if/else</li>
  <li>an Expression&lt;Func&lt;TSource,TValue&gt;&gt; version - as the first, but usable by arbitrary LINQ providers</li>
  </ul>
  
  <p>Additionally, using the Expression-based version enables Expression-tree re-writing, essentially inlining all the branches into a single composite conditional Expression, rather than using repeated invocation. I haven't checked recently, but in some early Entity Framework builds I seem to recall this being necessary, as it didn't like InvocationExpression very much. It also allows more efficient usage with LINQ-to-Objects, since it avoids repeated delegate invocations - tests show a match like the above (using the Expression form) performing at the same speed [marginally quicker, in fact] compared to the equivalent C# composite conditional statement. For completeness, the Func&lt;...&gt; based-version took 4 times as long as the C# conditional statement, but is still very quick and is unlikely to be a major bottleneck in most use-cases.</p>
  
  <p>I welcome any thoughts / input / critique / etc on the above (or on the possibilities of richer C# language support... here's hoping ;-p).</p>