Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

With nearly 60 answers to this question it's highly likely that your answer has already been posted. Please don't post an answer unless you have something new to say

Assume that your objectives are the same as for C#. I don't want an answer like "I'd write Python instead". I'm only interested in changes in the language itself - not in the standard library. Perhaps this would be interesting to discuss, but as it is shared between many languages it would be better to discuss this in another question instead.

Please post a single idea per answer; if you want to post several ideas, post several separate answers. Thanks!

share

locked by Yannis Rizos Dec 18 '12 at 16:59

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

closed as not constructive by Mark Trapp Aug 4 '11 at 19:24

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

1  
I think perhaps I misread this question when I answered it. Not that my answer is wrong, but there's tons of stuff I'd like to change for C#, but that is of course never going to happen. I will, however, very much like to contribute future improvements that won't break existing code. Bitching about missing features, that when added would break existing code might be all well and good, but it's not very constructive, unless you hope they create D# or some other new languages and just go with everything they learned from C#. –  Lasse V. Karlsen Sep 24 '10 at 8:30

56 Answers 56

I want to be able to have lambda expressions in custom attributes. For example...

[SomeAttribute(p => some_code(p))]
public string SomeField;

For reasonable flexibility, custom attributes should be able to be generic, so that the lambda expression can be properly typed:

[SomeAttribute<string>(str => some_code(str))]
public string SomeField;

This should be pretty simple to implement in the CLR and the C# compiler, too. Just turn the lambda expression into a static method on a special compiler-generated static type that contains all these methods for all those lambda expressions in custom attributes. Then compile the custom attribute data to one that contains the metadata token for that method. The CLR would recognise that the parameter is of a delegate type and automatically turn the metadata token into a delegate by calling Delegate.CreateDelegate() when the custom attribute is requested.

share

Having previously worked in C++ before C#, I really miss templates. Generics are close, but you can't specify non-types as a generic parameter. C++ template parameters allow typenames and primitives (int, enum, etc.). C++ templates also allow defining specializations. This allows for a wide variety of compile-time specialization. This is entirely useful when portability of generics is not a requirement.

share

Provide a macro system similar to Python's decorators, or maybe just make attributes more powerful. Using dynamic proxies or IL rewriting for simple AOP features like tracing or transactions is just overkill.

share

I'd change the name - C# - Google ignores that # character when you search for language-related things so you get unsolicited results for C/C++ stuff.

share

"raise" keyword for events

I'm tired of writing small methods just to trigger events thread-safely.

share

I'd like to see the ability to pass properties by reference. Like

int.TryParse(some_numeric_string, out MyProperty)

It's already been done in VB, so it's definitely possible.

share
3  
This would go well with a better design for out and ref which I suggested earlier, but of course due to backwards compatibility we can’t have that :( –  Timwi Sep 23 '10 at 11:33

Smarter if statements ie:

object foo = GetAnObject();
if(foo is string) 
    Console.WriteLine(foo.ToUpper());//foo is typed as string
else if(foo is int)
    Console.WriteLine(foo + 2);//foo is int
share
1  
programmers.stackexchange.com/questions/2815/… is basically the same idea, but implemented better. –  Timwi Oct 28 '10 at 14:46

Some syntactic sugar for the long-winded type-check-and-cast:

if (obj is MyType)
{
    var o = (MyType) obj;
    <use o>

e.g.

if ((var o = obj as MyType) != null)
{
    <use o>

or something a bit less ugly and more thought-through.

Better still, perhaps some special support for polymorphic extension methods. Code like the above is often the result of writing an extension method that would really have been a virtual method with overrides had it been implemented in the original class.

share

Sometimes I miss friend class and functions. They are quite powerful in some scenarios.
Apart from that they can also help in unit testing private methods of a class.

share
1  
Yes, definitely. My answer provides a Microsoft Connect link where I make a suggestion that might possibly fit within the .NET ideology (I doubt true "friend" would). –  romkyns Nov 24 '10 at 23:34

Mine's a fairly simple one - i'd have preferred it if properties and methods were virtual by default.

share
5  
Like in Java IIRC... Not sure it would be a good idea. Designing a class for inheritance is not as easy as it seems, because there are lots of cases you need to consider to make it solid. See Eric Lippert's articles about the brittle base class problem. –  Thomas Levesque Oct 18 '10 at 8:12

I would add Duck-Typing. Think of it as implicit interfaces. If an object implements the set of methods that compose an interface it is considered to implement that interface, even if the class does not explicitly name it.

share
2  
+1, but the right technical name for this is 'structural typing', not 'duck typing'. –  missingfaktor Oct 25 '10 at 4:09

i'd have preferred if LINQ to SQL is compatible with the others database types (Oracle,MySQL,PostgreSQL...)

share
7  
That's more of a libarary/tooling issue than a language feature. –  Mark H Sep 22 '10 at 12:07
1  
No, use NHibernate. ;) –  Henrik Feb 12 '11 at 23:15

I would make the language and also the common language runtime have yet more static typing with; kinds, monads and type-classes. It would allow all the generic constraints suggested above, on both methods and properties.

This discussion on channel9 shines some light on why this would be great in a multi-core world. Principally it would allow you to encapsulate state changes into the type system, allowing for greater library optimisation and improvements.

share

Eliminate "ref" and "out" parameters

Surely there has to be a better way, I cringe every time I has to use a BCL method with ref parameters (like TryGet)

share
  1. Improved support for defining local helper functions. Anonymous methods bring disproportionate runtime + code-size overhead, can't be generic, and recursive anonymous methods are very clumsy.

  2. Support for a generic type parameter constraint specifying constructor signature(s).

  3. Support for a generic type parameter constraint specifying method/property signature(s).

  4. Nullability should be handled consistently across reference and value types and disabled by default. "nullable string" and "string" should not be represented by the same type.

  5. A module system like SML's. The closest things C# has to approximating this are generics + interfaces and neither can unify multiple implementations of a set of related types and functions.

  6. Allow a default value to be specified for automatically generated property getters/setters

  7. Convenience features stolen from functional languages: pattern matching expression, let..in expression, etc.

  8. Extension properties, extension constructors.

share
4  
Next time, please post separate answers, not a list of several in one. Thanks! –  Timwi Sep 22 '10 at 10:44
3  
Just so you know, I would have upvoted a couple, but I don't want to upvote the rest... so no upvote at all. –  romkyns Sep 22 '10 at 10:51

Remove static entirely, and replace with pure for methods and threadlocal for fields. Any data to be shared between threads should be passed as immutable data.

share

One thing that I miss from my C++ background is const correctness. i.e. do not allow constant objects to be changed.

share

Case-sensitivity.

I'd make C# autocorrect case like VB .NET does, so that whether you type in all caps or all lower-case or a mixture, your code comes out in the correct case once you move off the line.

It vexes me greatly when I type the name of a class, but I don't happen to capitalize it, and C# pretends it has no idea what I'm talking about.

share
1  
VB's case insensitivity feels decidedly clunky to me. (And I started with a VB language.) –  Nick Oct 25 '10 at 8:05
2  
Upvoting! There is really no need at all for case-sensitivity. Humans just don’t think like that. –  Timwi Oct 28 '10 at 14:45
2  
I wonder if I would've gotten better votes on this if I hadn't mentioned "VB .NET". –  Kyralessa Nov 5 '10 at 3:54
1  
In principle, case sensitivity is an enormous pain in the ass. In practice, intellisense makes it trivially easy to use properly, so now you have all of the benefits of case sensitivity without the hassle. Having worked with VB before, and now with C#, I would never go back to the ambiguity of case insensitivity. –  Robert Harvey Nov 24 '10 at 17:57

Get rid of the var keyword.

Allow fall-through cases in switch() without having to jump through hoops.

I'd love a version that's less entangled with the framework that could be used to generate native code. C# is a lot like Delphi (thanks, Anders!) which used the Borland C++ compiler back-end. There's no reason C# couldn't do the same with MSVC.

Support for inline assembly. Just because I'm crazy like that.

A neat trick would be to build something that compiles C# into C++. You'd get to keep succinct syntax, a great object model, good exception handling, etc. I know there's no 1:1 correspondence between the two languages on many points, but it's possible. Yeah, I'll get right on that (not).

share
5  
What is wrong with the var keyword? Much nicer than having to deal with a swarm of types –  Casebash Sep 27 '10 at 23:10
1  
It introduces inconsistencies in code. If you change the way a variable is used, it can change the type that it is resolved to. It's just lazy. –  David Lively Sep 28 '10 at 16:03
5  
You see it as lazy, I think telling the compiler something it already knows is a waste of keystrokes and meaningless ceremony. C# needs more type inference, not less. Switching from F# to C# feels like a giant step backwards, most days. –  Joel Mueller Oct 1 '10 at 19:11
4  
Linq wouldn't exist without the var keyword. They're required for anonymous types. –  Thomas Levesque Oct 18 '10 at 8:20

Enums that actually represent a contiguous set of numbers should be permitted for array indexes. Sure, you can easily cast them but that doesn't let the compiler protect you from mistakes. This would also apply to bools.

share
1  
I wasn't the downvoter, but I'm curious to know what scenarios that would solve? –  Dean Harding Oct 18 '10 at 11:22

I want indexers not to limit modification. like this:

...
// MyList<T>
public this[int index]
{
get{/*do something to return value*/}
set{/*do something to set value*/}
}
...

so:

MyList<MyPersonClass> lst = new MyList<MyPersonClass>();
lst.Add(SomePeople);
lst.Add(SomeOtherPeople);
lst[0].name = "Fred";    // error
lst[1].last = "McKenny"; // error
share
4  
Indexers don't limit modification. The error you mention only occurs if you make a list of structs, and that's for a good reason. Your last two lines aren't calling "set", they are actually calling "get", and you are modifying the value returned. But structs are copied around, so not having an error there would just modify a temporary and discard it. Note that it works fine for actual classes. –  romkyns Apr 17 '11 at 1:18

I would like to be able to add white space to values inside of enums. I know this seems minor but it actually comes up a lot.

share
1  
Sounds like you are using ToString() on your enums to generate user-visible text. Bad practice. How are you going to internationalise that? –  Timwi Feb 22 '11 at 20:38

Not sure if someone put something about automatic casting:

int age = 70;
var foo = "John Lennon would be " + age + " years old";
Console.WriteLine(foo);

//---- output
John Lennon would be 70 years old
share
3  
You know, if you just create a new console project and paste this exact code into the Main method, it will produce that exact output :))) –  romkyns Oct 28 '10 at 9:07
2  
As romkyns already mentioned, C# already does exactly this. Furthermore, however, I’m downvoting this because if it didn’t, then I would prefer if it were not added because it destroys some of the static typing and makes it very easy to make the kinds of mistakes that normally only occur in dynamic languages (e.g. “The names are: String[]” because you forgot a string.Join...) –  Timwi Oct 28 '10 at 14:31

First about this, is that I don't like the way this question is posed specifically the requirement of one answer for post, since that is a call for spamming.

So, I would leave all my answers in one post, and let people vote accordingly, and if they want specify the one they like or don't in the comments to this answer.

  1. I would go and remove everything that only has one use, since there is probably some other way of doing that without that change;

  2. Make the language more stable, so that it don't change as the versions of visual studio or .net change, that would do a lot for the language adoption, since it is what java always had, and java is the language of the seven lifes.

  3. Remove lambda expressions, since delegates are more general and do the same.

  4. Remove the var keyword, or add the requirement that you either use vars (dynamic types) or static types, since it is a mess to find both of them in the same function!

And thats all, folks...

share
2  
It seems that you have an incorrect understanding of what “spam” means. None of the answers are unsolicited; nor are they adverts; nor are they addressed directly at large numbers of recipients. I’m going to downvote this because I disagree with one of your bullet points and I can’t vote on them separately. –  Timwi Feb 22 '11 at 20:41
2  
① is too vague; what are you even talking about? ② C# is more stable than Java; there have been long and painful discussions about how to avoid even the most minor breaking changes in C#; ③ that would be a breaking change, duuuhh (and also a dumb one; lambda expressions are no less general. If anything, remove the old delegate syntax); ④ Clearly you have no idea what var does; it has nothing to do with dynamic typing. — Well, looks like I ended up disagreeing with all of them, not just one... –  Timwi Feb 22 '11 at 20:45

I'd get rid of the syntax litter like {} and ;. And var (which makes a C# programmer a VB.NET programmer)

share

I would restrict var to enumerable query results (probably would change the keyword to query at the same time), create a contextual keyword called anon to deal with anonymous types outside of query results, and then make the class name optional on the right side in an initialization statement.

It would cut out utter crap like

var mystring = "lol"; // not permissable, lazy bum
var randomObject = ThisFunctionNameMeansNothing(); // get the freak out

While still cutting down on space produced by generics and long class names

MyRidiculouslyLongClassName<string, int, Foo> myClass = new();
share

Not the answer you're looking for? Browse other questions tagged or ask your own question.