Operator Constraints with Generics
An often suggested feature is to add a Number interface to numeric types so you can use arithmetic in generic methods. I don't think that quite feels right. But numbers do already share an interface of some sort: operators.
Why not this:
public static int Sum<T>(IEnumerable<T> seq) where T : operator(T=T+T){ .. }
This would even work for your own types, like vectors or matrices, or even DateTime and string (but that last one would be a bit non-idiomatic).
Constructor Constraints with Generics
When I found out you can constrain to new(), I was really surprised that you couldn't constrain to for example new(int, string). And I've definitely had use-cases where this would have been really useful.
Expanded Support for Dynamic Typing
While some might argue that it would make C# just more complex, I don't think it would. I really don't see any reason why full-blown static and full-blown dynamic typing can't exist side by side, where you use the one that makes sense in the current situation. I think while it would make the language more complex in terms of number of constructs, it would simplify the usage of the language. I've been doing dynamic typing ever since I first started using C#, it's just that I've been using reflection for it. I'd say by far most of my uses of reflection involve getting late binding capabilities, why not integrate it more into the language?
And when I mean expanded support, I would like the language to expand on the current dynamic, which is a good start, but not quite there yet. I would like to have something more like JavaScript, so I could say:
dynamic obj = new Foo();
int value = obj[aVariable].Method();
But that is not possible at the moment unless type Foo implements the right interfaces.
Currently, this would take:
var obj = new Foo();
object temp = obj
.GetType()
.GetProperty(aVariable)
.GetValue(obj, null);
int value = (int)temp
.GetType()
.GetMethod("Method")
.Invoke(temp, null);
Awful and painful.
JavaScript-style dynamic object literals
Another nicety would be the support for object literals. The new { Foo = 1, Bar = "string"}; is nice, but it generates a class with readonly properties, when sometimes, I want to change properties or even add new ones. And like I use reflection to have late binding, I have used many Dictionaries to support just that.
Instead of:
var dict = new Dictionary<string, object>
{
{ "Foo", 1 },
{ "Bar", "string" }
};
dict["Foo"] = 2;
dict["NewProperty"] = Something();
dict["Bar"] = "a new value";
I would like to see:
var obj = new dynamic
{
Foo = 1,
Bar = "string"
};
obj.Foo = 2;
obj.NewProperty = Something();
obj["Bar"] = "a new value";
And sure, the above Dictionary example is pretty clean, but usually you can't use the object initializer syntax.
Another use-case for this is when using LINQ to SQL, say you have this:
var customers = (from c in context.Customers
select new
{
c.Name,
c.ID,
Foo = FunctionThatCantBeTranslatedToSQL()
}).ToList();
That crashes because you use a function that has no supported translation to SQL.
So you need to do this:
var customers = (from c in context.Customers
select new
{
c.Name,
c.ID
}).ToList();
var result = from c in customers
select new
{
c.Name,
c.ID,
Foo = FunctionThatCantBeTranslatedToSQL()
};
It's really painful when you select 10+ columns from the database, and you need to repeat them all just because you want to set one new value on the object, for whatever reason.
Why not just:
var customers = (from c in context.Customers
select new dynamic
{
c.Name,
c.ID
}).ToList();
customers.ForEach(c => c.Foo = FunctionThatCantBeTranslatedToSQL());
The whole new dynamic construct could just be syntactic sugar for:
dynamic obj = new ExpandoObject();
obj.Foo = 1;
Null Safe Member Operator
Instead of doing:
var obj = Foo();
Bar value = null;
if(obj.Bar != null && obj.Bar.Something != null)
{
value = obj.Bar.Something.DoSomething();
}
You can do this with Groovy's null safe member operator:
var obj = Foo();
var value = obj?.Bar?.Something?.DoSomething();
Easier Immutable Types
This is a hard one.
Currently, one way to do immutability is to use a wrapper like ReadOnlyCollection<T> and wrap an ICollection<T> with it. And much like Nullable<T> is a wrapper around a value type to support "null" values, why not introduce a language construct that automatically generates wrappers like ReadOnlyCollection<T> in a very simple way?
class Foo
{
public int ID { get; set; }
public string Name { get; set; }
}
..
private Foo# _member;
public Foo# Something
{
get
{
return _member;
}
}
Foo# would be a distinct type from Foo and just compiler magic for an automagically generated class.
Of course, the question is, what does Foo# look like exactly? Does it only expose automatic properties like in Foo by making them get only? Because if it also exposes normal properties and methods, there's no guarantee that they don't change the object.
I have no idea, honestly. But I thought the concept was interesting.
Mono.Simd
It would be nice if .NET 5 had something like Mono.Simd, providing auto-vectorization for certain types, or preferably by decorating types with special attributes. But that last option sounds very hard, I don't know if it's possible at all. Just highly optimized Vector and Matrix types that utilize SIMD units of CPUs would be most welcome.
Nested Iterators
As described in this paper by Microsoft researchers, a proposal for a more efficient and simpler way to iterate over (among others) recursive structures. I'll admit that I don't understand the paper, but I do know the proposal will improve the following scenario:
public override IEnumerable<int> Foo()
{
yield return 1;
yield return 2;
foreach(var i in base.Foo()) yield i;
}
By allowing me to write:
public override IEnumerable<int> Foo()
{
yield return 1;
yield return 2;
yield return base.Foo();
}