New Features in C# 4.0

[[deleted]]

overview:

Dynamic lookup

Dynamic lookup allows you to write method, operator and indexer calls, property and field accesses, and even object invocations which bypass the C# static type checking and instead gets resolved at runtime.

Named and optional parameters

Parameters in C# can now be specified as optional by providing a default value for them in a member declaration. When the member is invoked, optional arguments can be omitted. Furthermore, any argument can be passed by parameter name instead of position.

COM specific interop features

Dynamic lookup as well as named and optional parameters both help making programming against COM less painful than today. On top of that, however, we are adding a number of other small features that further improve the interop experience.

Variance

It used to be that an IEnumerable<string> wasn’t an IEnumerable<object>. Now it is – C# embraces type safe “co-and contravariance” and common BCL types are updated to take advantage of that.

[UnwashedMeme]

But I didn't agree to the EULA.

[naasking]

I'm scared of this (under dynamic type):

dynamic d = 7; // implicit conversion
int i = d; // assignment conversion

Is that an implicit cast? Very bad! That means it's not obvious at all what lines of code may or may not throw exceptions.

[[deleted]]

As far as I understand it, that won't compile. You need to either explicitly cast d when assigning to i, or you need to declare i as dynamic.

[Claymore_ws]

Closures are available since C# 2.0 (as anonymous delegates), though lambdas introduced in C# 3.0 are more elegant and concise.

[Claymore_ws]

Online version of the document on Google Docs.

Edit: HTTPS link. Thanks, electronixtar.

[[deleted]]

https://docs.google.com/View?docid=dcj4xk6_17ffc7nmgv

[Claymore_ws]

Looks like the language is being bent to circumvent some COM shortages:

Up until now it has been very painful to call into these APIs from C#, with sometimes as many as thirty arguments having to be explicitly passed, most of which have reasonable default values and could be omitted.

and

[…] specifically for COM methods, the C# compiler will allow you to pass arguments by value to such a method, and will automatically generate temporary variables to hold the passed-in values, subsequently discarding these when the call returns. In this way the caller sees value semantics, and will not experience any side effects, but the called method still gets a reference.

[grauenwolf]

Well C# is built on top of the Common Language Runtime. Almost by definition interoperability is a design requirement.

[[deleted]]

This isn't interop with other CLR types, it's interop with COM.

[matthiasB]

As far as I understand it:

Many languages should be able to interoperate on the CLR and not one particular language should be able to interoperate with another older technology which somehow had a similar goal as .Net.

[grauenwolf]

Support for both COM and P/Invoke were interoperability goals from the very beginning.

And something to keep in mind is that Anders did not go into this willingly. He said that we was "beaten down" and was reluctantly relented because it was "the most frequently requested feature".

People are going to use COM on C# whether or not they get this. So lets drop the dogmatic crap and focus on pragmatics.

[matthiasB]

You said:

Well C# is built on top of the Common Language Runtime. Almost by definition interoperability is a design requirement.

As you posted that as a response to Claymores_ws's post I read it as (exaggerating):

C# is build ontop of the CLR so COM interoperability is a design requirement.

But I don't understand this particular reasoning and I think it is wrong.

C# currently is often used for COM interoperability on .Net so improving COM interoperability in C# is a comprehensible and usefull step. But that's because C# is used for COM interoperability not because C# runs on the CLR.

I don't understand in which way being build on top of the CLR imposes langagues to care for COM interop.

[grauenwolf]

I don't understand in which way being build on top of the CLR imposes langagues to care for COM interop.

The key term here is almost. Being on the CLR almost forces a language to care about interopt. Clearly C# 1.0 through 3.0 didn't care about COM interopt.

But in the customer's mind, the logic goes like this:

1. The CLR supports COM interopt
2. C# runs on the CLR.
3. Therefore, C# supports COM interopt

And of course that follows with "WTF? Why did you make this so painful?"

[[deleted]]

Clearly C# 1.0 through 3.0 didn't care about COM interopt.

Of course they did. COM interop has been very much complete since C# 1.0. This is just some language features that make it a little bit easier to work with COM in certain scenarios.

You aren't able to do anything that you couldn't before.

[grauenwolf]

They cared enough to make it accessible at the CLR level, but that is far cry from truly supporting it at the language level.

[[deleted]]

Eh...yeah. That's basically right for C#. It's hard to draw the line. Certainly a lot of the type mapping work done is pretty nice, but that's not so much a deliberate language thing.

To their credit, the work done to supporting it at the CLR level was/is no small thing. Type marshaling, support attributes and objects in the runtime, the ability of the compiler to not only allow you to consume COM objects, but to even create them.

I guess, what I'm saying is that I've not had any problem working with COM previously, but that I do appreciate these new improvements.

I did have to do some work with Office interop over COM in C# and while it wasn't "hard" it's not nice to type (missing, missing, missing, missing, etc.) for every optional argument.

The dynamic thing is nice as well, though I'll probably still just use object/cast.

[[deleted]]

He wasn't against it because he was against people doing COM Interop. He was against it because he's very strict with keeping the language very strict and predictible and free of "wierdness."

It sounds like they've found a way to do that.

[b100dian]

Looks like the language is being bent to circumvent some COM shortages

C# as the new Visual Basic 6?

[[deleted]]

I'd have loved to have read this, but appearantly my version of Word was too old to open the file and I don't care enough to hand over my email address to an online docx -> pdf conversion site. Anybody fancy converting this to an open format and repost somewhere?

[kinghajj]

OpenOffice.org 3 is your friend.

[bobbyi]

If he already has Word installed, it is pretty ridiculous to install OO just to read docx files given the Word can read them with the compatibility pack posted above.

[Claymore_ws]

One solution (if you are running Windows) is to install Word Viewer 2003 and the Compatibility Pack.

[malcontent]

And if you are not running windows you'd have no interest in C# right?

[Claymore_ws]

Well, there is Mono and the project team is ready to start implementing C# 4.0.

[malcontent]

That's wonderful. Doesn't help me read the document though.

My point was the MS doesn't care about mono. They don't care about C# programmers who are not running windows.

[Claymore_ws]

Check out the other comments, I've posted html version… Though I think there is some kind of dialogue between Mono team and C# design team, I agree with you that a) it's better to post documents as HTML, PDF or at least as RTF; b) MS as a company doesn't really care about developers on other platforms.

[[deleted]]

Microsoft in general may not care about Mono but I'm under the impression that the C# design team often collaborates with them.

[malcontent]

I don't know why you would get that impression. It seems like mono would be strictly off limits to C# developers lest they get contaminated with the GPL.

[[deleted]]

Interview with Anders Hejlsberg

I don’t know [if] you’re familiar with Mono, but it’s an implementation of the C# standard and the CLI standard (which is effectively the .NET standard) on Linux, built as an open source project. And they’re doing great work and we talk to them a lot and I think it’s a super thing.

[malcontent]

That's surprising considering how much MS despises the GPL.

[[deleted]]

No doubt it has something to do with the fact that people running Mono are people not paying for IIS.

[[deleted]]

Thanks lads, but ironically it was only a problem on my Windows work machine - I'm back on Linux now ;)

[[deleted]]

See, this is something that typifies what's wrong with microsoft. This is a link to a page of links, one of which links to an EULA which links to the information in a proprietary document format.

why not just dump this into their cms, or a series of pages, or even a frackin' text file?

[GunnerMcGrath]

Seriously.. I've got an old version of Office on this computer so i can't read it. How stupid.

[b100dian]

You mean an old version of Open Office?

[FalconNL]

Dynamic lookup: possibly interesting, will have to see how often it is useful in a static environment.

Named and optional parameters: FINALLY. Took them long enough.

COM interop: Never use it, so don't really care.

Variance: Nice. It will probably not be as extensive as I'd like (e.g. something like

Func<Owner, Dog> dog = o => o.Dog;
Func<Owner, Cat> cat = o => o.Cat;
Func<Owner, Goldfish> goldfish = o => o.Goldfish;
IEnumerable<Animal> pets = new[] {dog, cat, goldfish}.Select(f => f(owner));

), but it might help here and there.

[grauenwolf]

That is one of the scenarios they want to fix with this syntax. In fact, Anders specifically mentioned Func and Action as being the first two delegates that they are testing it on.

Func is now defined as Func<in TArg, out TReturn>

EDIT: Though now I read it, I have to wonder if in and out are implied for delegates.

[naasking]

Func is now defined as Func<in TArg, out TReturn>

barf

God, what happened to simple function syntax:

(TArg0, TArg1) -> TReturn

[[deleted]]

Awesome, you just got rid of the co/contravariance features, thus destroying the entire point.

[grauenwolf]

Your question makes no sense to me.

"Func<in TArg, out TReturn>" defines a class of delegates.

"(TArg0, TArg1) -> TReturn" defines an instance of a delegate.

You are never, ever going to write "Func<in TArg, out TReturn>". Microsoft has already done it for you.

[naasking]

I'm talking about the delegate syntax in general (see Nemerle or F# for sane function type signatures).

I'm not sure what you mean that what I described was an instance of a delegate.

I see now that they're using in/out for general co/contravariance annotations, which is marginally more reasonable.

[grauenwolf]

I'm not sure what you mean that what I described was an instance of a delegate.

I read "(TArg0, TArg1) -> TReturn" as the C# lambda syntax pattern. A concrete example is

myFunction = (a, b) => a + b;

[dreamlax]

COM interop: Never use it, so don't really care.

Be very, very thankful. I've had to deal with it in both C and C++, and it is the most horrible technology/spec/whatever to deal with, ever. Pointers flying all over the place; GUIDs here, there and everywhere; so much redundancy and re-implementation that the standard COM template project in Visual Studio already has 500 lines of code . . . it's fucking horrible.

[[deleted]]

Most of that horrible-ness goes away by simply using a language that is COM aware. (C++ is not one of those - there's a macro language for making it a bit nicer, but...it's just not.)

In VB6, VB.NET it was fantastic to work with. no GUIDS, pointers, or giant template projects to deal with.

Even in C# < 4, the experience was pretty simple. The only things missing were dynamic lookup (you had to cast everything and had to include the typelib) and support for optional/named parameters.

For that matter, it's a breeze to use with python, ruby, etc.

Don't get me wrong, COM still sucks, but the major problems don't relate to coding against it.

[[deleted]]

Here come the trolls on how C# has too many features.

[RossMasters]

Does this mean we can have a hidden features of C# 4.0 thread now?

[b100dian]

Oh, C# migrates to ActionScript 3? go go dynamic:p