Sometimes you may hear oppinions that there are too many changes introduced to the C# and/or too fast. That people get lost and confused about all this new syntax and feature added here and there. And while one may argue or not, I would like to look at this topic from a different angle – what are you missing in C#? What single functionality would you enjoy the most?
I’ve asked the same question here and there (in Polish) and here are aggregated results, sorted by popularity, with some additional remarks from my side:
1. Discriminated unions
The clear winner is a possibility to use “discriminated unions”. There is an ongoing proposal about them already. The most often mentioned wishes here are to have good pattern matching support (we hope so!) and F# DU compatiliby (unlikely, like in the case with records).
2. First class void/aka Unit
Another functional-like feature is to have void having type representation, like unit in F#. This avoids treating differently methods that return nothing (void X()), and methods that return something (int X()). So, for example, allows more flexible generics handling, as now Action == Func<unit>. If you feel interested, read “Unit isomorphisms” by Mark Seemann explaining that “The C# and Java keyword ‘void’ is isomorphic to a data type called ‘unit””.
3. Pipe operator
Yet another feature making C# more F#. Besides many functional use cases, it would allow, for example, to create readable “fluent” code without writing dedicated extensions methods.
4. Type interference of methods
Having var as method return type seems like kind of natural extension where var can be used currently. In places where the compiler is able to unambiguously infer the return type (greetings Jared;)) we could write:
|
1 2 3 |
public var M() { return 0; } |
5. Anonymous interface implementation
A long-living feature request to have possiblity to anonymously (via anonymous objects) implement interfaces:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
public class C { public void M2(IMyInterface iface) { } public void M1() { M2(new { Value = 44 }); } } public interface IMyInterface { int Value { get; } } |
It has been recently reincarnated (again?). And if you really, really need it, you can use dynamic magic from libraries like impromptu-interface.
6. Shapes aka type classes
The idea to allow definining abstractions/extension over types is considered for some time, and with the current proposal it looks like:
|
1 2 3 4 5 6 |
public extension IntZero of int { public static int Zero => 0; } WriteLine(5 + int.Zero); // in the scope of the extension, int has a Zero property |
But it goes even further in the form of “shapes” (type clases), as the proposal explains: “Interfaces abstract over the shape of objects and values that are instances of types. The idea behind type classes is essentially to abstract over the shapes of the types themselves instead”. So you can define a shape like that:
|
1 2 3 4 5 |
public shape SGroup<T> { static T operator +(T t1, T t2); static T Zero { get; } } |
And then, the primary purpose of a shape is to be used as a generic constraint, so you can write:
|
1 2 3 4 5 6 |
public static AddAll<T>(T[] ts) where T : SGroup<T> // shape used as constraint { var result = T.Zero; // Making use of the shape's Zero property foreach (var t in ts) { result += t; } // Making use of the shape's + operator return result; } |
Avoiding repeating myself, I encourage you to read the entire proposal and the discussions.
7. Primary constructors
Writing constructors to initialize many fields (dependencies?) is tiresome and requires a lot of names copy-pasting. The idea is to introduce “primary constructor” that automaticaly wires up everything. After introducing source generators, they can be implemented with the help of that. Thus, I’m not sure if they have a future in C#.
8. constexpr from C++
Well, this one is pretty exotic for C# developers probably. C++ allows to use constexpr specifier which “specifies that the value of a variable or function can appear in constant expressions”. But in general, this is more about what and when compiler is able to detect “deterministic output” so compile time constant may be infered/calculated. I invite you to read a pretty broad discussion about it, covering many various use cases and scenarios.
Funny
Besides those above-listed, I’ve received more funny (or serious?;)) answers and I would like to share them too:
1. Make .NET faster and faster – ok, this is not funny. It is just more about the runtime, not the C# itself. So while I fully agree, it should not be on the above list.
2. Multiinheritance – yes, we can have sort of it using default implementations in interfaces. But, still it is not the same. Funny joke, right…
3. Coroutines and fixing async/await – I treat it as a joke, while definitely it may be not and it does require runtime changes:)
4. More F#/TypeScript features – sure! 🙂
5. string.parseFromUserStory(„…”) – bad naming case, it will not be implemented 🙁
6. Inline assembly – always welcomed for performance😍
Summary
Do you like those features and would like to see them added in the next C# versions? And what are you missing in C#? What single functionality would you enjoy the most? Please, share in the comments or social media!
Good list. I’d like to add a suggestion: compiler-assisted error handling.
Right now, the only way to see what exceptions a method will throw is to read the documentation of every method, or run the program and see what goes wrong. Both aren’t great.
Java has checked exceptions, but they’re a pain to use. Having some sort of metadata on a method for the errors, and a much less verbose try/catch syntax would help a lot. e.g. http://joeduffyblog.com/2016/02/07/the-error-model/
Another pick from me would be built-in support for deconstructing non-tuple types.
This has been present since C# 7 – any type can be deconstructed if you provide a
Deconstruct()method to tell the compiler how …See https://docs.microsoft.com/en-us/dotnet/csharp/deconstruct#deconstructing-user-defined-types
Please, I need more immutability. I am so sad I can’t const all the things.
I’d love type classes, first class
Unit, and maybe discriminated unions.However, currently the biggest issue for me is with .NET itself: its lack of support for proper 64-bit arrays and now also Spans. Who’s brilliant idea that was in 2017, that users will never need 64-bit span is beyond me.
Private fields for properties
public string Name
{
private string name = “”;
public get { return name; }
public set { SetPriperty(ref name, value, “Name”); }
}
To stop developers accidentally setting the field.
I’ve been coding in C# since 2001. Yes, you saw that correctly.
How about NONE? As more and more coding shortcuts get added, the list of things I need to learn in case I come across it grows. New language additions may shorten the code, but reduce the understanding. Eventually the code will be nothing but {,.=> And try google that when you’re unsure what it is.
PLEASE, let’s not add more to C#!
Multiple dispatch – without having to use tricks like casting to dynamic.
Lots of C# devs think method overloading is multiple dispatch – they don’t realise that method overloading is not resolved at runtime. So C# probably should be doing multiple dispatch, if that’s how developers expect it to behave.
Is there such a need to turn C# in functional language? See what happened to C++ with such attitude: someone just sat down and invented Rust.