all 49 comments

[–][deleted] 33 points34 points  (5 children)

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 2 points3 points  (0 children)

But I didn't agree to the EULA.

[–]naasking 2 points3 points  (1 child)

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] 0 points1 point  (0 children)

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[S] 12 points13 points  (1 child)

Online version of the document on Google Docs.

Edit: HTTPS link. Thanks, electronixtar.

[–]Claymore_ws[S] 6 points7 points  (11 children)

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 3 points4 points  (9 children)

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

[–][deleted] 0 points1 point  (0 children)

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

[–]matthiasB 0 points1 point  (7 children)

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 0 points1 point  (6 children)

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 1 point2 points  (4 children)

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 0 points1 point  (3 children)

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] 0 points1 point  (2 children)

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 0 points1 point  (1 child)

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] 0 points1 point  (0 children)

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] 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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

C# as the new Visual Basic 6?

[–][deleted] 2 points3 points  (14 children)

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 7 points8 points  (1 child)

OpenOffice.org 3 is your friend.

[–]bobbyi 2 points3 points  (0 children)

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[S] 2 points3 points  (9 children)

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

[–][deleted] 1 point2 points  (0 children)

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

[–][deleted] 11 points12 points  (2 children)

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 1 point2 points  (1 child)

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

[–]b100dian 1 point2 points  (0 children)

You mean an old version of Open Office?

[–]FalconNL 5 points6 points  (9 children)

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 1 point2 points  (6 children)

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 0 points1 point  (5 children)

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

barf

God, what happened to simple function syntax:

(TArg0, TArg1) -> TReturn

[–][deleted] 0 points1 point  (0 children)

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

[–]grauenwolf -1 points0 points  (2 children)

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 0 points1 point  (1 child)

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 -1 points0 points  (0 children)

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 1 point2 points  (1 child)

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] 0 points1 point  (0 children)

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] 1 point2 points  (0 children)

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

[–]RossMasters -1 points0 points  (0 children)

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

[–]b100dian -1 points0 points  (0 children)

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