4 ms·
I think OP has something like this in mind: let x = if ... then let a = frob() Foo + a else Baz `x` is never in an invalid/uninitialized
by latkin 11y ago
I think OP has something like this in mind:
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.
- noblethrasher 11y agoYou 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).
- louthy 11y agoOf 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. [1] https://github.com/louthy/language-ext https://github.com/louthy/language-ext
- noblethrasher 11y agoAgreed 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#.