Inside C# 4.0: dynamic typing, optional parameters, covariance and contravariance

Posted By: Charles | Oct 31st, 2008 @ 9:28 AM | 82,808 Views | 22 Comments

Formats:

C# Program Manager Mads Torgersen and C# compiler developers Eric Lippert, Chris Burrows, Samuel Ng discuss (and whiteboard) the details inside C# 4.0's dynamic type, optional parameters and default parameter values, and new support for COM interop (should make Office developers giddy). Samuel, Chris and Eric were very busy solving some really hard problems to pull these new features off. It's great to learn about these new features from the people who actually implemented them. Classic Channel 9!

So, how does C# 4.0's dynamic type work, exactly? What does "more COM friendly" really mean? Covariance and Contravariance? Optional parameters with default values and parameter re-ordering? Why? How? Tune in.

Enjoy!

(my apologizes for the slight glitch at the middle of the interview. My camera bluescreened! Fortunately, data captured before the system failure was stored successfuly, but a little tiny piece of the conversation was lost)

Tags: CSharp, CSharp 4.0, Programming, Programming Languages

Rating:

spivonious

How is the dynamic type different from the Object type?

edit: nevermind, I never knew that C# couldn't do this. VB has been able to do this since the beginning.

gaurav.net

awesome cool...
Thanx Charles...

Just Downloading ..can't wait..

Initially on listening about dynamic features i was not sure whether its good to include them..

But after all the announcements & pdc talks.., i m really loving C# v4 , now we don't hav to write all the plumming code..that actually is pain..

Ch9 ROCKS

Fact Pandit

I am not sure whether "dyanamic" key word is a good feature or not. I think, if MS wants to provide run time object type resolution support in C#, it should have provided with a library or some thing. I don't like C# becoming another C++.

I like the new covariance feature

I like the named parameters, but I don't like changing the order. Also I don't like optional parameters feature. That creates an illusion and makes programmers to worry on non business aspects.

My suggestion for optional parametes is:

In the method declaration Use attributes to configure default values and while the programmer making invokation of that method let intellisence kicks in for filling the defaul parameteres.

Coder4Hire

Stop adding (polutting) new key word and syntax to C#. It is a complex programming language as of now. The more C# bloating with new stuff in each release (2.0, 3.0, 3.5, and now 4.0), the more it becomes a weaker programming language. Comparing the number of keywords and programming constructs of C# to C/C++, Python, etc. and you will see how bloated C# has become.

How about try to provide new features without modifying language for a change.

obrienslalom
(2 2 2 3) *3 | 3 3 3

In reply to Fact Pandit

#Oct 31st, 2008 @ 1:57 PM

Optional parameters can be a good thing when considering their example. I remember automating some work in excel from c#. I'm stealing this example from here :

oChart.ChartWizard( oResizeRange, Excel.XlChartType.xl3DColumn, Missing.Value,
   Excel.XlRowCol.xlColumns, Missing.Value, Missing.Value, Missing.Value, 
   Missing.Value, Missing.Value, Missing.Value, Missing.Value );

[[ becomes ]]

oChart.ChartWizard( 
    Source : oResizeRange, 
    Gallery : Excel.XlChartType.xl3DColumn, 
    PlotBy : Excel.XlRowCol.xlColumns
    );

The new version could be a one-liner if i wanted it to be. I find the second version much easier to read, and you get to be explicit about your parameters. Intellisense was a lifesaver, I agree, but I do see the benefit of the new feature compared to just letting intellisense take over.

DouglasH
Just Causual

In reply to Coder4Hire

#Oct 31st, 2008 @ 2:49 PM

Hmm, ok I know we had the new language at .net 1.0, C# 1.0, and added generics in .net 2.0 C#2.0. extended Generics and added lamdas and extension methods in .net 3.5 C# 3.0.

Enlighten me on Language additions in .net 3.0??

Each addition to the langauge so far has added little complexity in the return on productivity.

As a matter of fact the co contra varient stuff should have been there in 2.0.

The no pia enhancements is just a no brainer given the fact that .net has to interact with Com code.

I will take any language enhancement that simplefies that impedance missmatch. Or for that matter interacting with win32.

I further Hope Pray, Jump Up and Down Screaming Waving my arms Please please PLEASE implement compiler features to take advantage of the Recursion optimizations offered and .net 4.0 CLR.

Douglas

Pon

I'm half way through, and I have a question.

Say you have the following:

dynamic x = ...

x.M(1,2,3,4,5,6,7,8,9,10);
x.M(1,2,3,4,5,6,7,8,9,"a string");
x.M(1,2,3,4,3.14159);
x.M(DateTime.Now);

Will the generated delegate check parameters one at a time? eg, like this:
if (param1Type == typeof(int))
{
   if (param2Type == ...)
   {
    ...
    if (param5Type == int)
    {...}
    else if (param5Type == double)
   { ..}
} else if (param1Type == DateTime) {}

Or will it check each one repeatedly?

Also, will there be any sort of profile-guided optimisation in that delegate? Say that it notices x.M(DateTime) is called the most, will it reorder the tests?

cburrows

In reply to Pon

#Oct 31st, 2008 @ 10:59 PM

Hi Pon,

At the risk of distraction from my main point, let me tell you what we do right now, and then I'll address your concerns about performance. The way the C# runtime binder works is that once it's located a correct "behavior" for a particular call site, it feeds that behavior back to the DLR, which manages the delegate. The DLR sequences these rules given the order that it receives them from the binder, and they do not interleave. Which I think means that in your example, we "check each one repeatedly." Furthermore, at the level of the delegate generation, there is no profile-guided optimisation.

But that doesn't address your deeper concern about performance. Let me assure you that we care very much about the performance of the code that we're going to gen and that you're going to use, and we plan to measure it, set goals, and make changes to achieve those goals, both in the C# runtime binder and in the DLR. So it may be the case that the behavior I just described will change before we release the final version, or it may be that it's irrelevant. Consider that the delegate is going to be jitted and that the jitter could, in some cases, perhaps, perform the first optimization that you mention without the DLR having to worry about it. Obviously, in that case we wouldn't worry about it.

I can't say what particular changes, architectural or otherwise, will come about because of our performance investigations, but I can say that there will be some.

chris

Rvz
Zepp

Looks like you guys want to have the cake and eat it too Smiley

From what you guys say, C# is moving from a pure classical language to add features of prototypical languages like javascript.

Will you guys also be using JSON style name/value pairs to create heirarchical data structures with the "dynamic" data type? I am guessing you will allow the developers to also "augment" the "dynamic" data type in a similar fashion. If you do, how are you going to provide for encapsulation (everything is public access)

The covariance and contravariance stuff is cool. When I saw the example, I was thinking "duh, but of course"

I like the optional/default parameters and named parameters too. I have been wanting that for atleast 4 years now Smiley

Keep rocking
-Rvz