C# 4.0 language features

[Pavel Minaev]

An "official" document covering the new language features has finally
been posted:

http://code.msdn.microsoft.com/csharpfuture/Release/ProjectReleases.aspx?ReleaseId=1686

(warning: it's available in .docx format only)

Not that much, to be honest. Named arguments is the only feature that
is likely to be used, and, while certainly nice to have in and of
itself, it really is long overdue (as Anders himself said on PDC). The
rest seem to be too specialized, though I can think of some ways to
creatively abuse IDynamicObject and dynamic dispatch to e.g. walk XML
trees, XPath-style (similar to first-class LINQ to XML support in
VB9).

Your thoughts?

 

[Ivan]

I can see "dynamic" type being abused a lot by VB developers. It's like
"Object" in VB6

 

[Anthony Jones]

An "official" document covering the new language features has finally
been posted:

http://code.msdn.microsoft.com/csharpfuture/Release/ProjectReleases.aspx?ReleaseId=1686

(warning: it's available in .docx format only)

Not that much, to be honest. Named arguments is the only feature that
is likely to be used, and, while certainly nice to have in and of
itself, it really is long overdue (as Anders himself said on PDC). The
rest seem to be too specialized, though I can think of some ways to
creatively abuse IDynamicObject and dynamic dispatch to e.g. walk XML
trees, XPath-style (similar to first-class LINQ to XML support in
VB9).

Your thoughts?

I don't think the variance changes are too specialised. Support for co and
counter variance where appropriate will be very welcome.

I also expect to see much great take up of COM interop with this version. I
for one have kept COM interop and arms length, but it would seem that MS
have come to accept and even re-embrace COM as something that is still here
to stay for a long time.

Optional Parameters and overload resolution looks a bit messy. An example
given is:-

M(int i, string s = "Hello");
M(int i);

M(5);

In this example M(int i) is the winner. That being the case the only way I
can see the former overload getting called is:

M(5, s

Its wierd enough that parameter identifiers have become significant (not
just the types and parameter order) but the above is even stranger.


Interesting hints in the document RE HTML DOM using IDynamicObject? What
does that mean? Is there some deep hidden project that has HTML DOM
implemented on the DLR? Perhaps I'm reading too much into it.

 

[Peter Morris]

I also expect to see much great take up of COM interop with this version.

I am greatly looking forward to avoiding this as much as possible

 

[Pavel Minaev]

I don't think the variance changes are too specialised.  Support for coand
counter variance where appropriate will be very welcome.

Actually, I highly suspect that they will be only used in a few
fundamental interfaces such as IEnumerable, IComparable and
IEquatable. Declaration-site variance is of somewhat limited utility,
because too many useful interfaces are neither covariant nor
contravariant as such, even though they can be used in either fashion,
depending on what needs to be done with them (such as IList - indexer
is covariant, Add() is contravariant, and plenty of methods only use
one but not the other). Usage-site variance, a la Java, is much more
permissive.

I also expect to see much great take up of COM interop with this version. I
for one have kept COM interop and arms length, but it would seem that MS
have come to accept and even re-embrace COM as something that is still here
to stay for a long time.

Yes, this was a bit of a puzzler, really. I would've expected
migration of existing COM-only APIs to native (at least to the
immediate client) .NET ones, but it seems they chose to improve
interop instead.

Optional Parameters and overload resolution looks a bit messy.  An example
given is:-

M(int i, string s = "Hello");
M(int i);

M(5);

In this example M(int i) is the winner.  That being the case the only way I
can see the former overload getting called is:

M(5, s

Well, it is obviously a corner case, and a harmless one at that.
Overloading rules for optional arguments are actually quite sensible,
and follow the guidelines established for varargs/params.

Its wierd enough that parameter identifiers have become significant (not
just the types and parameter order) but the above is even stranger.

Parameter identifiers were always significant in .NET as a whole,
since they are part of public signatures, and since at least one other
MS language (that is, VB.NET) had named arguments since version 1.

Interesting hints in the document RE HTML DOM using IDynamicObject?  What
does that mean?  Is there some deep hidden project that has HTML DOM
implemented on the DLR?  Perhaps I'm reading too much into it.

I think it's just an example of what can be done. What they're
probably referring to is the way you can walk HTML DOM in JavaScript
in a browser - you know, using element names as properties. So <div
name="foo"><div name="bar"/></div> becomes document.foo.bar.

 

[Pavel Minaev]

After some discussion of new C# 4.0 features with Eric Lippert, it
seems that dynamic is not quite as obvious as it seems, and can be
abused in some rather creative ways. It's not just a dynamic receiver
that triggers dynamic dispatch - it's _any_ argument that's dynamic.
But, in this case, the arguments (including the receiver) that are
statically typed are used to constrain the candidate method group at
run-time. For example:

class Base
{
public void Foo(int i) {}
public virtual void Foo(float f) {}
}

class Derived : Base
{
public override void Foo(float f) {}
public new void Foo(string s) {}
}

Base b = new Derived();
object arg = 1; // hide actual type at compile-time
b.Foo((dynamic)arg); // calls Base.Foo(int) - overload resolution at
runtime
arg = 1.2f;
b.Foo((dynamic)arg); // calls Derived.Foo(float) - overload
resolution at runtime yields Base.Foo(float) + virtual/override
dispatch as usual
arg = "abc";
b.Foo((dybamic)arg); // does NOT call Derived.Foo(string), since
variable b is declared as Base; runtime exception!

This is interesting. We've all seen those clever LINQ hacks (monads
etc); now the challenge of the day is to find some way to abuse
dynamic in a similarly non-obvious fashion