The Actipro Blog

All the latest UI control development news from Actipro

SyntaxEditor .NET Languages Add-on - Type Inference


Today I wanted to provide a quick series of screenshots that demonstrate our type inference features found in the SyntaxEditor .NET Languages Add-on for WPF/Silverlight’s resolver.  These features are still in development and are not yet available in the current build.

Before we begin, be sure to check out our previous blog posts on .NET Languages Add-on development.

What is Type Inference?

Type inference is the ability for the C#/VB resolver (part of our new add-on features) to examine an expression and try to determine its resolved type result.  For instance, say you specify a typeof(int) as an expression.  We know that the C# typeof call always returns a System.Type object, so our resolver attempts to look up the type definition for System.Type in the assemblies you indicate to reference.  Once we have the type definition, we can drive automated IntelliPrompt features.

Type inference is vital for determining what type a variable is that was defined with var, which requires an expression initializer.  It’s also used when examining arguments to methods, since when there are overloads available, it must figure out what type each argument is and compare that to the defined parameter types to pick the best overload for which arguments are present.


As mentioned in previous posts, we’ve started work on automated IntelliPrompt quick info for the C#/VB languages already.  The following samples will show off type inference features. 


In the first screenshot, we are hovering over the WriteLine method.  As we all know, Console.WriteLine has over 10 overloads.  Our type inference engine identified that the x parameter passed into it was a System.Int32 and it found the best WriteLine overload to take an Int32 argument.


Now we get a bit more complex.  We still pass in an Int32 parameter x but we create a new implicitly-typed variable called y that has a binary operator expression.  When you add an Int32 and a Double, it results in a Double.  Our engine has logic built-in to recognize these scenarios, so this time when we hover over WriteLine, we get the overload that takes a Double instead.


Now let’s switch to generics.  Here, we’ve made a Gen alias for the System.Collections.Generic namespace.  Our list parameter to the method is a List<Double> type.  We create an implicitly-typed variable called item that invokes the indexer of the list.  When we hover over item, we see it is a Double, which is correct since the list is a list of doubles.  There are numerous levels of recursive resolution operations going on here to make it all come together.


And finally we hover over WriteLine again, and it appropriately picks the overload that takes a Double.


This is really very neat stuff, but it’s very time-consuming to code.  Yet we’re working hard on it every day and are taking the time to make sure it provides the best C#/VB code editing experience outside of VS 2010 that is available.  Your end users will really love these features and the intelligence baked into them!

Comments (1) -

April 15, 2011 at 11:29  

Mike Strobel United Kingdom

Just wait until you have to bind lambda expressions with implicit parameters to generic delegate types with variance (and do so as part of method overload resolution, with multiple compatible candidates).  Then the type inference logic gets even more complicated Smile.  Thankfully, the C# spec tells you exactly what you need to do.

Pingbacks and trackbacks (1)+

Comments are closed