[Updated 10/29/2004 with item #6]

I figured that for my 100th post I'd put something out there that I hope to get lots of feedback on.

Each day as I'm coding I invariably stumble across a language feature that just doesn't sit right with me.  That, or I get to thinking, I wish the BCL's supported X function or Y capability.  While I'm not coding, however, I tend to forget these items until I once again go crashing headfirst up against it.

I've given this some thought, but will probably be amending it a bit here in the next few days as I expect I'll encounter a few more.  So, without further ado, here's my .NET wish list (NOTE: I'm not addressing several issues that I know will be fixed within Whidbey such as scoped accessors on properties, etc):

1. CONSTANTS

I really wish I could declare globals (public constants) at the namespace level without having to resort to an enumeration or a class when the values aren't conceptually enumerated or non-integers.  I'd love the ability to create public and/or internal constants like this:

namespace SomeNamespace {
   internal const int MaxIdLength = 15;
  
   public class Employee {
      public const int MaxNameLength = MaxIdLength;
      // ... class code here ...
   }
}

1a. DEFINES

Along the same lines as constants, having the ability to perform a #define would be very powerful.  Where a constant can potentially be exposed outside the library as a value, a #define only has applicability to the compiler preprocessor.

#define S_RES_APPLICATION_TITLE 10001

namespace SomeNamespace {

   internal sealed class Res {
      internal static string GetString(int id) {
         // return the designated resource value
      }
   }
 
   internal sealed class EntryPoint {
      public static void Main() {
         System.Windows.Forms.MessageBox.Show(Res.GetString(S_RES_APPLICATION_TITLE));
      }
   }
  
}

Now there might be some issues of type safety here that would need to be addressed, but this capability would be extremely enabling and powerful...hearkening to what C++ developers can already do.

2. TRY..CATCH..FINALLY VARIABLES

I am of the firm belief that if a variable is declared within the try block its scope should extend to both the catch and the finally blocks.  As it stands, in order to use a variable in the various blocks you must declare it outside the try..catch..finally.  In other words, if I declare a SqlConnection within a try I can't Dispose() of it in the finally...I must declare it before the try.  This can lead to poor code.  First of all, the object's scope now extends beyond its intended usage, a bad practice as far as I'm concerned.  This would be ideal:

public string GetName(int id) {
   try {
      SqlConnection cn = new SqlConnection("...");
      // get the name and return it
   }
   finally {
      if ( null != cn ) cn.Dispose();
   }
}

There might very well be some technical reasons behind why this is so danged difficult, but I believe it would lead to much clearer code and the developer's intentions would be more easily maintained.

3.  SCOPED INHERITANCE

I get fed up with having to scope my base classes the same as the deriving classes (or vice versa).  Oftentimes, I am wanting to declare a base class to be internal to my assembly, but have a public class that derives from it.  I am using the base class internally for private functionality and object organization, but I don't need it exposed.  Yes, I know I can probably use an internal interface and a private class to accomplish something similar, but that's not what I want to do.

If in fact I do have to expose the base class (which I might be amenable to), I'd at least like to have it internally abstract and publically sealed.

Ideally:

internal abstract Base {
   // ... some methods here ...
}

// here sealed would be implied by virtue of the fact that the
// abstract base class is not publically exposed
public class Derived : Base {
   // ... implementation ...
}