Some thoughts here. I’m starting with C# as the ‘base’ language here, because mostly I like it. I’d just like to see some changes. Most of these are in Nemerle… some of them are not.
Static methods which take only the type of object to which they belong as a parameter can be called on instances, even null ones, and the compiler will be smart enough to figure out that it just passes a null parameter to the static method.
Like this:
if (MyString.IsNullOrEmpty)
There is no point to having to write if string.ISNullOrEmpty(mystring)… useless extra drivel and confusing to people who don’t already know what that means. Sure Static methods go with the ‘class,’ but we’ve just told the compiler what sort of class we have when we declared the variable… so let it use that information instead of us developers having to write it again.
Values will be True if they are not Default. if(MyString) means if MyString is not null. This functionally can be defined and overriden for custom and inherited classes.
int x = getSomeIntegerFromSomewhere();
if (x) means if X is not zero.
Null means the same as Default. Value Types can be null. This is useful in generics.
Compiler will allow more generic (covariant) parameters in delegates even if a matching signature isn’t found for all cases. An exception will be thrown if you USE a signature that doesn’t exist, but not just because you theoretically COULD:
For example:
public delegate string GetStringDelly(object value);
public string StringFrom(int value);
public string StringFrom(double value);
public string StringFrom(DateTime value);
All of those are valid targets of the delegate as long as you only pass those types of values, the compiler is happy and you suck if you violate the rules. If you pass in a byte[], eat error, you deserve it. This is allowed so that we can store delegates in a hash table, and have each one call a different signature. Like a switch statement on steroids.
None of this operator overloading bullsh*t. If an operator doesn’t have a standard meaning, then it will confuse the daylights out of people. Sure it’s fun for the obfuscation contests. Name your METHOD something useful or make a MACRO.
Macros are legal, and can be used as inline syntax in your code. Yes. You too can extend the language 
Not because you feel the urge to write a language, but becasue you need the shorthand.
A function is a valid value. You can declare delegates, yes, but also define functions as parameters and values inline.
This also implies that I can finally use Properties of instances as Output parameters in functions. Can I tell you how much I hate stuff like this:
string SomeDateString = GetADateString();
if( !string.IsNullOrEmpty(SomeDateString))
{
DateTime attemptedDate = new Date();
if (DateTime.TryParse(SomeDateString, out attemptedDate))
{
MyPerson.DateProperty = attemptedDate;
}
}
it should be more like:
DateTime.TryParse(SomeDateString, out MyPerson.DateProperty);
You can access properties of classes by string name at runtime without killing the system performance, or requiring extra permissions. If you don’t have the permissions. Dynamic calls and accessors respect conventional access methods. Meaning if the developer marked it as internal, and you are not in their library, you cannot ever gain access to it. Ever. Never. Why reflection in .NET lets you get at things you shouldn’t be able to is a mystery to me. It’s useful sometimes, but it’s a bad idea. Really. If you ever find this to be ‘useful’ and you put it into production code, you’re asking for trouble in maintenence. I mean, the exposed namespace is what you’re supposed to see, and thus, what the library writer will leave intact, or likely so, in future versions. If you go poking about in private methods and fields, and it breaks, that’s your own lookout, and you shouldn’t be able to break the rules that the original developer set for you.
Code generation at runtime is legal, and can happen without full trust. Certain functions or methods will not be accessible to generated code, but you can do the basics without full trust. This runtime generated code cannot be persisted to disk, and cannot be called by other assemblies other than that which has generated it. The fact that you can’t, and that say.. the XmlSerializer can really BOTHERS ME!
Interfaces can contain static members as well as access modifiers in any place that you can write them in a class. Why not?
This is shaping up to be a cross between Nemerle and what I think c# 3.0 will be… with of course a few differences. It is a mix of concepts between ML, OOL, and dynamic languages that simply would make my life grand.
I’m on the fence about type inference… but sure.. why not. Throw that in too.
Eval() is implemented, but only for numeric and string expressions.. you can’t call methods of classes other than operators that are defined by the system… no going and injecting things into custom operators, because you can’t overload them. You cannot call macros in Eval().
Lazy instantiation can be declared in the same way that Nullable<> is currently in c# 2.0
Lazy<Person> p = null;
p.Address = foo; does not throw an exception, becasue I declared it as LAZY. It will call the default constructor, and then perform the assignment.
I know that a lot of this would be tough to have in the same language, and why don’t I ask for a villa on the moon while I’m at it? But, I’m just hypothetically postulating here… Nobody has to listen to me… I’m not asking YOU to write this language, I just want to explain what I feel are shortcomings, and say what I’d like to see.
Maybe I’ll just switch to Nemerle, and write a lot of macros.
