Why are you asking me about features for the next version of C#, when the 2.0 version hasn't even shipped yet?

A fair question.

One of the problems that we have in the tools division is the long lead time between the time when we're done with a product and the time that it's actually available to our customers. Delta a few small items and some bugfixes, the C# compiler is essentially done for Whidbey, so that's why we're thinking about the next version.

We've always had this offset, but because we're attempting to expose our designs much earlier than we have in past, it may look strange from the outside. As involving customers early on in design becomes more common, this should be less weird.

When we designed the using statement waaaay back in the first version of C#, we decided to call it using because we thought it had other purposes outside of the usual use:

using (StreamWriter writer = File.CreateText(”blah.txt”)){ ... }

Today I was responding to a customer suggestion, in which he suggested language support for the ReaderWriterLock class, so it could be more like the built-in lock statement. Unfortunately, ReaderWriterLock.AcquireReader() doesn't return something that's IDisposable, but it's pretty easy to add that with a wrapper class.

I spent about 15 minutes writing a wrapper, then I had a thought, did a google search, and came across this article, which already has it done. Plus, the version in the article probably wraps the whole class, and has likely been tested.

Last Sunday, we went on a short hike to the summit lakes at Stevens Pass Ski Area.

It was the first hike for us this season, and the first one with canine company.

The real trail starts at the top of the Brooks lift (roughly centered in the photo). But to get there, you get to climb 900' up a steep jeep trail (well, you can walk straight up the hill if you want). We started at 8AM to miss the heat, so it wasn't bad.

The trails to the lakes are fairly easy - mostly up and down, but the trail is pretty overgrown in places, so you'll need to spend some time pushing through underbrush.

The lakes are typical alpine lakes - shallow, and very pristine. I didn't take pictures at all of them, but here's one of the very tiny ones.

In other words, there is no guarantee that a local variable will remain live until the end of a scope if it isn't used. The runtime is free to analyze the code that it has and determine what there are no further usages of a variable beyond a certain point, and therefore not keep that variable live beyond that point (ie not treat it as a root for the purposes of GC).

Thanks for the awesome post Eric. I'd be interested in hearing more detail about the sorts of things that cause features to be rejected. Is it common to reject a feature that you think would be valuable only because of syntactic compatibility limitations (parser ambiguity, breaking change, etc)?

What are you thoughts on how language evolution should work in general (outside the confines of C#)? Do you think it would be possible to have languages that could more readily accept the type of extensions you've wanted to make to C# but couldn't?

For example, do you think there would be value in a language that added a layer of abstraction between the syntax presented to a user, and the persisted form? Eg. if a language was stored on disk as an XML representation of the parse tree, then you could evolve the language (add keywords, etc.) and rely on the IDE tools to intelligent present the code to the user.

I've been saving up this one for a while now.

It's common for us to reject some features because they aren't along the lines of our language philosophy.

It's also fairly common for us to reject a feature because we can't come up with a good syntax for the feature. Sometimes this is because we just don't like the constructs we come up with, because they are ugly, or they don't really make things simpler for the user, or they don't cover the right scenarios. The syntax we can use is heavily constrained by the existing structure of the language. Take a look at your keyboard, look at all the special characters, and tell me which ones aren't already used for something in C#. The list is very short, so we are constrained by the operators that are available. We're also constrained by whether our change would be breaking, and in what situations things would be breaking. C# 2.0 has no major breaking changes, and though that isn't an absolute rule for us, it's certainly a goal. Adding new keywords is, in general, a bad thing to do.

Finally, we're constrained by what the runtime can/will implement, and whether things can be implemented across languages. Some features only make sense if they're done in all the languages, but that means all languages need to agree before we do it.

Rick also asked about language evolution.

There are different opinions about this. Some believe that languages should never change. Others believe that they should be able to extend their language at will. An extreme example of this is Intentional Programming.

I think I'm one of the few people around who have actually played around with intentional programming. Conceptually, it's interesting, but in the real world, I think the “everybody designs their own language” approach is challenging at best. One can envision a world where the user representation is extensible but the underlying representation is standard, but I think that's a bad world to be in. It may be great for you, but it's probably not good for your team, or the poor guy who takes over your code two years from now. And there's a lot to be said for the “code in a text file“ world.

We have well-defined ways for users to add functionality - through classes, methods, interfaces, etc. I think that languages should only consider adding features when there is an obvious shortcoming to solving the solution through existing functionality. At that point, you need to understand those issues and determine whether the language solution is the right way to address the issue.

So I'm not big on extensible languages. Existing facilities - such as Macros in C++, do have their users, but are a disaster from the readability standpoint (both for the compiler and the developer).

We're starting to think about the release after Whidbey in the C# compiler team.

I know that it seems strange that we have just shipped the Whidbey beta, and we're already talking about what comes next, but we're fairly close to being “shut down” for the compiler right now. So, we're taking the “big picture“ perspective.

Since we're in this mode, now's the time to suggest things that we should add to the language and/or scenarios where you think the language falls short.

An ideal comment would be something like:

I'd like to be able to support mixin-style programming in C#

If it isn't obvious what you're suggesting, please provide a link.

It would also be good to suggest through code - something like:

I currently am forced to write code like

<ugly code here>

and it's really ugly.

I won't be able to respond to all comments nor will we implement all of them (or perhaps any of them), but we will consider all of them.

One of the questions about in the comments to my post on Apollo question asked “Why do we have a manned space program?

That's a fair question, but before I answer it, there are two things I want to talk about.

The first is to give credit where credit is due. A tremendous amount of really good science has been done by unmanned probes, and with the exception of the moon, virtually all our knowledge about the solar system has come from these missions.

The second is to be careful to define what we're discussing. When I talk about “a” manned program, I'm not necessaarily talking about the current manned program.

So, why should we have a manned space program. Well, you should be sure to go read some of the information written by NSS, but here's my opinion:

There is something about personal participation that fires the human imagination. Whether it's climbing Mt. Everest, travelling to the south pole, or flying higher than anybody else, people have always aspired to be the first to do something. Striving to accomplish that which is difficult is a defining human characteristic.

So that's the abstract reason. But there are also practical reasons.

The first reason is that space has the potential to provide nearly limitless resources. Whether it is possible to exploit them economically isn't yet clear, but if we could replace half of the world's coal-fired power plants with solar power satellites, we could make a tremendous reduction in the release of sulpher, radioactive elements, and greenhouse gasses. Clean power from space has a lot of appeal.

There are also opportunities around other resources. If we could mine asteroid iron, our reliance on environmentally-damaging mining on Earth would be reduced.

Given our continued population growth, the ability to spread out and get resources elsewhere is very interesting.

The final reason concerns the long-term survival of the species. We have good evidence to global catastrophe in the past, and without spreading out to other planets, it's fairly certain that such an event will happen again.

So, that's what I think, but those who are smarter and more informed than I am have written a lot on the subject.

35 years ago, two men came within 20 seconds of dying 250,000 miles away.

Hours after averting tragedy, a very young Eric Gunnerson got to stay up late to watch Neil Armstrong walk on the moon.

I was 5.

I've always been a bit of a space nut, and my memory is full of important points in space history:

Armstrong and Aldrin's lunar landing

Apollo 13

Apollo Soyuz

Skylab

The first flight of Columbia

The last flight of Challenger

The last flight of Columbia

But watching NASA the last 15 years makes me sad. Despite some good efforts to reform the culture and get back to the kind of organization that recovered from Apollo 1, NASA has not suceeded in reforming itself, and it's stuck with a hugely expensive shuttle and a space station without a clearly-defined purpose. The unmanned and astronomy programs continue to be excellent, but manned spaceflight has lost it's way.

At this point, I think you'd get a better result if you cancelled two shuttle flights and gave Burt Rutan and Lockheed Skunkworks the money for one flight, and let them work to advance the state of the art.

But having said that, I would like commemorate the dedication and sacrifice of all those involved in Apollo. Many sacrificed money and their family relationships to the cause. Some gave their lives. Gus Grissom, Ed White, and Roger Chaffee died in the Apollo 1 fire. Charles Bassett, Theodore Freeman, Elliot See, and Clifton Williams died in training mission plane crashes.

Here's hoping that this is not the last time that humans will walk on other worlds.

If you look at the definition of the generic collections classes, you'll see things like:

List<T>Dictionary<K, V>

What's up with those T's, K's, and V's?

If you look at our beta1 library design guidelines (can't find a published link right now) that suggests that you use single-character names for type parameters rather than longer, more descriptive names. But those guidelines weren't always there. In fact, before we had them, you might see a class like:

class Dictionary<Key, Value>{}

which seems reasonable enough. But one day, you're browsing code, and you look at a method:

public void Process(Key k){ // code here...}

What's Key? It looks like it's a type, and unless you know that there's a type parameter named “Key“, you're likely to be confused for a while. We therefore decided to use the single-character naming approach, and my experience is that it's worked pretty well.

When you're working on a generic class, you normally have a small number of generic type parameters, and therefore it's not that hard to keep them straight. When you're using them, C# intellisense is nice enough to give you a description for the type parameter so you remember what it is.

That is, it's nice enough to do that if you remember to *write* the description using the <typeparam> tag. The IDE will add this tag automatically when you type the /// before your generic class definition.

Unfortunately, the beta1 drop doesn't have these descriptions for the built-in collection classes, so you don't get any help right now if you type “List<“. We'll be fixing that.

Google gives high weight to blogs. In fact, google gives too much weight to blogs. Too often I've gone to research something that I only know a little about (say, training for a century) and found that my post is on the first page of results. Want to know what it's like to turn 28? I'm apparently the expert.

It does have its uses, however. Today I needed to find an old blog post, and I found that if I type:

In this class, I've fixed a byte[] array so I can pass it to an unmanaged method. I've included “UnmanagedFunc()“ in my program to illustrate what it looks like, but I would normally be calling a C function through P/Invoke in this scenario.

The problem with this code is that some C APIs accept null values as arguments. It would be nice to be able to pass a null byte[] and have that translate to a null pointer, but the fixed statement throws if it gets a null array.

Thr problem with the workarounds is that they are ugly, and they get fairly complicated if there is more than one parameter involved.

The language spec (section 18.6) says that the behavior of fixed is implementation defined if the array expression is null, so we could change our behavior so that fixing a null array would result in a null pointer rather than an exception.

Questions:

Have you written code where this would be useful?

Are there situations where the change of behavior would cause you problems?

TheServerSide.Com has a post up that references what Don Box and I wrote, and there are some comments that you might find interesting. And not just because of the nice things that Rolf said about me.

I agree with Cameron when he says:

The difference in the Java market is that the community is made up of peers. It is _not_ simply a vendor / customer relationship of convenience.

This was what I was trying to get across in my summary post around JavaOne. Though we've made some good progress in the community space, we're still not very open from the design side of things, and that's a challenge we should take on.

One of the things that we've done in Whidbey is add some extra IL instructions to improve the debugging experience. This allows you to (for example) set a break on a closing brace.

Because /o- is the default setting, this means that performance if you just compile with “csc” will be slightly degraded in Whidbey. If you've been building without setting /o+ and you care about perf, you will want to change your code to throw /o+ explicitly.

If you're using VS release and debug configurations, this will be set automatically for you.

This week starts part of my favorite part of the summer, “Le Tour de France”. The tour is likely the hardest athletic challenge in the world. Last year, Armstrong covered 2100 miles at an average speed of just under 26 MPH, including 7 days of riding over mountain passes.

The best TV coverage is on OLN, though you need to get past the whole “Cyclism” thing. I recommend recording the early morning live broadcast, as they use different commentators for the afternoon recap.