These additions are all nice but most of them really aren't more than syntax sugar. What c# really really needs is stricter reference handling of objects, such as const * const in C. Now when you send an object into a library function you don't have the slightest idea what the function will do to your object. Take the simplest case of void Foo(List<string> bar). What will Foo do with bar? 1. Iterate it once and calculate something based on the contents. 2. Iterate it once and store references to all strings in the list. 3. Mutate the list by adding or removing items. 4. Store a reference to the list itself and modify it two days later from another thread causing a race condition because you thought you held the only reference to that list.
Case 3 could be excluded by using ienumerable here but in many other cases its not that simple.
I'm not asking for c++ and manual memory management here, just some kind of constraints on what a function may do with its arguments. I've seen case 4 cause so many bugs its ridiculous, it doesn't even have to involve multi threading before it gets nasty.
Now when you send an object into a library function you don't have the slightest idea what the function will do to your object
There are more languages then C# which tend to have these problems, and for all of them these problems can be avoided in a number of ways merely by applying the typical good practices and well known design patterns. For instance just giving your functions proper names (examples 1. GetLongestString 2. StoreReferencesToAllStrings (still hacky, not sure if there are proper usecases for that?) 3. RemoveDuplicates 4. InstallList or so) and making sure functions do One Thing only will get you a long way in preventing problems. Not saying it is easy, but I've been using C# for at least 5 years and don't really recall problems with it. Did have problems with weak event handlers disappearing due to gc but after learning it it didn't happen again.
Case 3 could be excluded by using ienumerable here but in many other cases its not that simple.
I'm not asking for c++ and manual memory management here, just some kind of constraints on what a function may do with its arguments. I've seen case 4 cause so many bugs its ridiculous, it doesn't even have to involve multi threading before it gets nasty.