I don't know how you can say the C#'s development is practically stagnated. Evidence? Async/await was just added in C# 5.0.
But without comparing it to F#, Microsoft has not polished the C# 3.0 design. Expression trees are still half implemented (no way to call one exptree from another). MS created anonymous types, but neglected to add simple types like tuples (let alone anything more advanced). Type inference is still ridiculously limited in scope:
- Neither parameters nor members can be type inferred.
- Local function vars can't be type inferred (because they chose identical syntax for expression trees).
- Generic constraints can't be type inferred.
- Generic parameters have limited inference. If one parameter can't be inferred, you _must_ specify all of them.
return Tuple.Create(valueA, valueB);
But both of those changes are very much sugar, neither of them would make the language more powerful.
[1]http://msdn.microsoft.com/en-us/library/system.tuple.aspx
As far as sugar - if the language is Turing complete, then every feature is syntactic sugar. You need a perverse definition of power to suggest that being able to properly handle tuples via deconstruction doesn't increase the power of the language.
The difference in this case is just a couple of lines of code.
Compare that to C, where it would be a great deal more work!
(Of course a good deal of this difference is in C# using and abusing the heap so much.)
> As far as sugar - if the language is Turing complete, then every feature is syntactic sugar. You need a perverse definition of power to suggest that being able to properly handle tuples via deconstruction doesn't increase the power of the language.
Well yes, but there is the matter of how much mental effort the transformation from idealized software engineering concept to actual implementation takes the programmer.
Tuples in C# don't require that much mental effort, sure it'd be great if they were a native part of the language, but they aren't unreasonably unwieldy.
That said there are certainly times I wish multivalued returns were a natural part of C#!
Of course the problem with returning multiple unnamed values is that you can easily lose semantic information. (obviously I am ignoring comments above a function) It is not too hard to indicate the meaning of a single return value from a function, but beyond that it can get a bit harder.
(Yeah I know the scripting language people don't care, but with every passing day I am more firmly in the static typing side of things, I like my fields with both names and types!)
All that said, I can only imagine how much more productive the 80s 90s would have been if C had supported multiple return values from a function. In the very least Windows programming and HRESULTs would have been a fair bit saner!
(I do find it funny that seemingly no compiler vendor ever extended C to add multiple return values into it!)
C# is truly a great language; it was just created by people who have different priorities than you (or I) do.
The benefits of built-in features you mention can be accomplished by special-casing as an optimization. Zero downside language wise, only requires some level of more resources for the compiler writers. For debugging, seems like the same amount of work; either way it has to reconstruct the "async stack". Best of both worlds, no downside.
C# is a great language, probably the best of the mainstream ones I'd say. But I still find it severely lacking in some areas, with no justification other than lack of desire/resources (type inference being the #1 case).