I'd like to have the ability to create a generic delegate to specify strong types of parameters. I imagine this should be fairly simple for the compiler team, but don't know if it's come up before. This would save casting in event abstract event handlers. For instance...

delegate void EventHandler<T>(T sender, EventArgs e);
delegate void EventHandler<T, E>(T sender, E e);

I want to say every event handler I've seen sends this (or Me, for you VB hedz), so there's no reason we should have to cast, leaving room for invalid casts and declining performance (albeit minor) for developers who aren't keen on these issues.

I can't remember where I first saw the AddNew() method Add(new) concept -- or, at least the concept behind it -- but I liked it. I'd really like to see the same thing added to all generic collections. For instance...

List<Person> people = new List<Person>();
Person person = people.AddNew("Michael", "Flanakin");

I admit, this doesn't save you a whole lot of typing, but it is very convenient.  Essentially, I'd like every constructor to be represented by a corresponding AddNew() method. So, if I have default, id only, and a first and last name accepting constructors, I want 3 additional AddNew() methods...

public Person AddNew();
public Person AddNew(int id);
public Person AddNew(string firstName, string lastName);

As is, generics alone cannot do this with the level of integration I'd like to see, which would include reusing XML documentation already in place for the constructor. You can, however, hack something to give you this capability by using the params keyword powered by reflection in the back-end. Of course, I'd be worried about performance with an implementation like that. I don't see this being added, tho. The cost of implementing it probably wouldn't be worth the 6+ characters you'd save ("new " + name of class + "(" + ")"). Then again, perhaps this could be a mod to generics, which is already lacking, when it comes to constructor constraints.

Edit: I realized after posting this that it wasn't an AddNew() method I was looking for, but simply additional Add() methods. While this would save an additional 3 characters, the "is it worth it" argument is still there. I'd still say its convenience makes its case, tho. Maybe I'm just lazy. I changed the code samples are referred to this idea as the Add(new) concept, even tho you don't actually use the new keyword.

I thought I mentioned this before, but I guess not. I really want to have the ability to create an interface which has protected members. An interface is all about forming a contract with consumers, right? Well, isn't a child class a consumer? I'd argue that it is. An example of what I'm looking for might be an interface for a domain object. I want everyone to get the id, but only want the class itself to set it. Another instance might be in a situation where you'd need to execute some method internally, like validate prerequisites for an event or something like that (see below). I typically need something like this when I want to enforce a standard implementation across the board.

public interface ICommand
{
    public long Id { get; protected set; }
    protected bool ValidatePrereqs();
}

Reported @ http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=291006

Edit: Looks like this is "being considered" for a future release. Not sure what that means, but we'll see.

Edit: Well, I guess "being considered" doesn't mean a whole lot. The idea was pretty much shot down by someone on the C# team. I feel like I didn't explain my point well enough; however, I understand his point. Essentially, protected members can only be accessed by child classes, so what's the point in having an interface member for a class that knows about its members? Sure, that makes sense, but that doesn't mean I don't want the capability. I guess I like it more for standardization than anything.

This isn't new, but I had to mention it. Since the inception of C#, I have wanted an equivalent to the VB with block. I believe I've heard that it won't be done, but that's not going to stop me from hoping. The idea is simple and it shouldn't affect the IL code that's generated from C#. This is merely a tool in which a developer could speed up development a bit.

Client client = new Client();
with (client)
{
    .FirstName = "Michael";
    .LastName = "Flanakin";
    .Coolness = CoolFactor.ToTheMax;
}

...should compile to...

Client client = new Client();
client.FirstName = "Michael";
client.LastName = "Flanakin";
client.Coolness = CoolFactor.ToTheMax;

I can see maintainability issues with a feature like this, but there are potential maintainability issues with the misuse or overuse of any tool.

This may not be a big deal, but I can see how it might be useful every once in a while. It's a good practice to catch specific exceptions so you're not randomly missing some crucial bug in your application. Sometimes you want to catch a small exception, but let others bubble up. As-is, you'd have to create multiple catch blocks to catch each individual exception or add code to check to see if an exception is of a certain type to decide whether or not to rethrow it. Doing a bunch of casting checks will be a performance problem -- granted, maybe not a huge one, but moreso than separate catch blocks, I believe (I haven't tested that theory).

Let me give you an example. Let's say you have a string value you need to convert to an integer and then use that as an array index. If the value can't be parsed, the conversion could throw three exceptions: ArgumentException, OverflowException, or FormatException. However, if you're directly feeding this into an array, you may end up with a good integer, but a bad index, which would result in an IndexOutOfBoundsException exception. With this, you may want the out of bounds exception bubbled, but handle the case of a bad number. Simply catching an Exception will obviously catch all situations. Instead, I'd like to see something like this: catch(ArgumentException, OverflowException, FormatException). Obviously, if you want to do something with the exceptions, you'd have to specify variable names for them, but you get the idea.

Again, this may not be a big deal, but I like the practice of catching all exceptions and dealing with them where they occur. I also admit that this may be a bad example -- anyone wanting to cover all bases would check the index, too. I'm simply noting one small example, tho. I'm sure I could come up with several others where developers make typical assumptions without catching the exceptions. Probably the most typical one is the NullReferenceException. Yeah, I caught you on that one, didn't I?

Here's something I just ran into this week: the need for a case-insensitive switch block. Why, you ask? Let me describe how I came across the issue. Code analysis reports excessive/unnecessary ToUpper() and ToLower() calls because they can become a performance problem -- granted, a minor one, but it's a hit nonetheless. Typically, this happens when you're comparing two strings and you don't care about their case. Instead of the ToUpper() call, code analysis suggests the use of String.Compare(), which can do a case-insensitive search. Well, that's great and fantastic, but when you're doing this in a switch block, that's not quite possible. I could've changed the code to use an if block, but that would've been more of a readability/maintenance problem. Basically, all I'm looking for is a switch block that accepts a string and a boolean value indicating whether it's case sensitive or not -- something like this: switch (string, bool). Behind the scenes, the compiler can change that to use String.Compare() inside an if block or whatever the appropriate IL should be. I imagine this performance benefit of such a feature would be somewhat minimal, but I thought the idea was interesting.

One thing that hasn't really caught on in the .NET world is the use of <thead>, <tbody>, and <tfoot> elements within tables. That's too bad because they can be very handy when working with styles. I'd like to see an option in all table-based controls to produce these elements. Perhaps a RenderTableSections property or something similar.