Everyone under the sun has done one of these, so I’m going to change tack a little.
Two things I wish Hejlsberg would nick from F# for C# 4.0:
Tuples – simple, ad-hoc types with members accessed by order rather than by name. Take the example of being able to return a host/port pair. In F# you can say:
let getHostPort(servicename) = let host, port = serviceBroker.GetDetails serviceName //this function returns a tuple (host, port) //this is what we return.
In C# you’d have to create a class (or worse, an inner class!), as anonymous functions don’t really keep well out of their function scope.
Options – are a nice way to handle null. I’ve always hated how you can end up with null as the return value of a function just because some lazy hack couldn’t be bothered throwing a decent exception, or in some misguided fit of premature optimisation thought it would be better to have me check the return value of everything I call against null.
Options are a way to declare that a variable can either be a typed Something, or a Nothing. Underneath, they use null to represent the Nothing, which is fine – it’s kept well away from me and the consumers of my code.
I can legitimately say that for a valid request there is no result right now, or throw an Exception on an invalid request. But the type of the return value is Option<T>, rather than a T which could be null. Nicer, see?
I’m sure there are more things, but this is a fairly good start. I’ve been writing F# for quite a few months now, and going back to C# feels dirty. C# is making great strides towards functional programming (with lambdas and anonymous types), and I’m no Functional evangelist, but I think those two would be a great practical addition to the language.
You have to be careful with Tuples. There are certainly situations under which they can be misused, and you should think carefully before you expose them via your public API. The values have no names, so your code (if it ever was) is no longer self-documenting, and difficulties with the way they’re implemented in FSharp.Core make reflection difficult. But used wisely, and with the right tweaks to the language, they could be a great boon.
With regard to constraints on your return values you should check out the capabilities being included under System.Diagnostics.Contracts. This allows you to use the Enusure() method to guarantees that a method won’t return null for example.
Another language feature that I was hoping for was type self referencing to cut down on a lot of refactoring work and such. More information at the URL below.
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=470524