3 ms·
That's not a "problem" in type inference, that's a design decision where lambda syntax can represent either delegates or expression statements. This is how LINQ
by Locke1689 11y ago
That's not a "problem" in type inference, that's a design decision where lambda syntax can represent either delegates or expression statements. This is how LINQ-to-SQL can take a LINQ expression and turn it into a SQL statement.
However, that doesn't mean we don't wish you wouldn't have to specify the type there -- that's why there's a separate proposal for local functions (https://github.com/dotnet/roslyn/tree/features/local-functions https://github.com/dotnet/roslyn/tree/features/local-functio...), which would allow
var inc(x) => x + 1;
- MichaelGG 11y agoYeah, I know the reasoning, I just find it faulty. It's confusing to not know if your code is code or turned into an expression tree. So with that, local functions will have different syntax than normal functions? I don't envy y'all on the C# team; it's gotta be difficult to try to advance it while maintaining backcompat. I just wish MS would put more money and clear marketing into F# instead of pretending like hacking up C# syntax is the only way to continue.
- Locke1689 11y agoI would read this[1] article on F# if you want the realities of the situation [1] http://ericsink.com/entries/fsharp_chasm.html http://ericsink.com/entries/fsharp_chasm.html
- MichaelGG 11y agoThat's an excellent post as Eric's a smart guy yet misses the real reasons. Eric's wrong about Swift, and the reason is illuminating. Swift has the full, unconditional support of Apple. Look at the splash pages for Swift[1][2]. There's no comparable page for Obj-C. The docs on Swift[3] make it clear that you're totally set and don't need to worry. It's obvious to any developer that choosing Swift is a good, safe, correct choice and you won't be left hanging. Microsoft chose not to do this for F#. Now compare to how MS markets C#[4] vs F#[5]. C#'s clearly sold as the general dev language for "rapid application development", whereas F# is to "solve complex problems ... such as calculation engines and data-rich analytical services". This sums up MS's attitude, which percolates to customers. F# is just for hyper-intelligent folks doing mathy stuff - not for us normal devs! C# should instead be pitched focusing on it's "familiarity and userbase" just like VB has "English-like syntax which promotes clarity"[6]. Inside VS and .NET overall, it's clear that F# is simply not getting the same level of support. So while Eric might be pointing out that "normal people", meaning the bulk of MS customers, are staying with C# this is just MS fulfilling it's marketing goals. MS refuses to reassure customers that F# can and should be considered for any application where C# is considered. Until that attitude changes, I would not be surprised if customers continue to do what MS says to do. I doubt it'll change. C# has no real competitor (Java's lightyears behind). They've got a proven track record of ignoring F#. Add in the politics and face issues going on (going off the history as well as comments from third parties that have been involved on both sides) and well, what can we really hope for? 1: http://www.apple.com/swift/ http://www.apple.com/swift/ 2: https://developer.apple.com/swift/ https://developer.apple.com/swift/ 3: https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/ https://developer.apple.com/library/ios/documentation/Swift/... 4: https://msdn.microsoft.com/en-us/vstudio/hh341490.aspx https://msdn.microsoft.com/en-us/vstudio/hh341490.aspx 5: https://msdn.microsoft.com/en-us/vstudio/hh388569.aspx https://msdn.microsoft.com/en-us/vstudio/hh388569.aspx 6: https://msdn.microsoft.com/en-us/vstudio/hh388573.aspx https://msdn.microsoft.com/en-us/vstudio/hh388573.aspx