let x =
if ... then
let a = frob()
Foo + a
else Baz
`x` is never in an invalid/uninitialized state, and it's immediately clear exactly what code contributes toward computing its value.
Somewhat related, you can also define nested functions in F#, which is very convenient and tidy. No need for a pile of one-off private helpers at the same syntactic level as your public APIs - just tuck them inside the members which need them.
You can define nested functions in C# in for form of lambdas or anonymous delegates. Admittedly, it's still not quite as pretty as it could be because we don't get to use automatic type propogation (e.g. the `var` keyword).
Of course you could do many things to make C# closer to F# (I've devoted a whole library to coercing it [1]). My preferred approach would be:
var x = ...
? Foo + frob()
: Baz;
Or to be truer to the original (using my lib):
var x = ...
? map(frob(), a => Foo + a)
: Baz;
But the idioms of the language mean that in the real world you see the ugly version with the associated risks of uninitialised variables. I applaud the C# team for the direction they're taking. I suspect C# will end up closer to Scala than it will to F#, which isn't a bad niche for it to be.
Agreed that C# will probably end up closer to Scala. For instance, it's already more straight-forward and elegant to simulate and use type classes/traits in C# than it is in F#.
Somewhat related, you can also define nested functions in F#, which is very convenient and tidy. No need for a pile of one-off private helpers at the same syntactic level as your public APIs - just tuck them inside the members which need them.