Yes, the rest of the dev community is I suspect hugely envious of working in such a team. Must be extremely exciting :-)

I've moved almost completely over to C# from VB.NET, but there is one piece of syntactic sugar that I miss from VB...With.

Especially when you are dealing with structures or objects that are nested extremely deeply (see XNA or even some ASP.NET code-behind scenarios), With was a godsend.

I'd love to be able to do something like...

with (a = Some.Deep.Object.Or.Structure.That.Would.Take.Forever.To.Type.Or.Use.Intellisense.For)

{

a.Property = x;

a.Property2 = y;

a.Property3 = z;

a.Property4 = w;

}

Admittedly, the compiler would just expand a out, but even so, that little shortcut it what I miss more than anything.

You already have it:

var a = Some.Deep.Object.Or.Structure.That.Would.Take.Forever.To.Type.Or.Use.Intellisense.For;

a.Property = x;

a.Property2 = y;

a.Property3 = z;

a.Property4 = w;

It even takes fewer characters than your suggestion

I think the ex-VB crowd may be missing something like this:

with varname = Some.Deep.Object.Or.Structure.That.Would.Take.Forever.To.Type.Or.Use.Intellisense.For;

{

   .Property = x;

   .Property2 = y;

   .Property3 = z;

   .Property4 = w;

}

This way a programmer could only change the variable name in one spot.

I'm more worried about something in the Some.Deep.Object.Or.Structure.That.Would.Take.Forever.To.Type.Or.Use.Intellisense.For returning null.

With the move to more immutability method chaining becomes much more attractive except for that pesky null ref exception. You can make null objects but that has downsides in a language that is still largely imperative. You can make a chain-safe extension method for every method, but that seems like a bad idea. I'd like to see something like a new chain-safe opperator .. which would return the default of the method return type if calling on null.

Some..Deep..Object..Or..Structure..That..Would..Take..Forever..To..Type..Or..Use..Intellisense..For

... or something like that.

It's worth pointing out that if all you want is to create a very short-lived temporary variable that has limited scope, you can do it with the following (admittedly odd-looking) construct

{

  // new local nested scope

  var a = Some.Deep.Object.That.Takes.Forever.To.Type().Foo;

  // do stuff in this block...

}

Like I said, it does look a bit strange, but it's a feature of the curly-brace languages going all the way back to C.

Mmmm. Watched the video. Not much in the way of upcoming features. Just how Eric likes to code by himself :P.

Is there any analysis done that talks about the general distribution of programs that are CPU-bound vs IO-bound? It seems there is a lot of talk about parallelizing programs and how important that is. It would seem that this would be particularly beneficial for programs that are CPU-bound, but possibly disadvantageous to programs that are IO-bound. Though I realize a function that does IO would not be pure and unlikely to be parallelized.

In general, I'm wondering about the target market for parallelization. It would seem that it would be the intersection of the set of people who do scientific computing and the set of people who have trouble doing their own threading.

Hi Eric

I have a question unrelated to this topic (but I can't see your email address anywhere, so here it goes) :

It appears that a x64 version of msscript.ocx does not exist.

Why so?

TIA

Rudif

"We can finally do in csharp what we have done in jscript for 8 years..."

Nice  ;)

Daniel

Hi Eric,

(late reply)  I really liked this -

"Design Patterns are just the failure of abstraction in the programming languages"

Does it mean we would see more of design patterns coming out of the box in C# 4.0 ?

Jomit