4 ms·

This tuple stuff is a mess. From the RFC: >This is based partly on the assumption that the proposed C# 7.0 tuples will use struct representations for at least s

This tuple stuff is a mess. From the RFC: >This is based partly on the assumption that the proposed C# 7.0 tuples will use struct representations for at least some small tuple types. This is what F# had to begin with! They were sort of pushed into using a heap-allocated type via System.Tuple, in the name of compatibility with the rest of .NET. Frustrating! It's also sad to see no mention of really improved tooling, to put F# on the level of C#. MSCorp paid some lip service, well overdue since the F# guys are the ones that gave them generics which was the biggest thing technical advancement .NET had over Java.

phillipcarter 10y ago
> It's also sad to see no mention of really improved tooling, to put F# on the level of C#. Could you clarify what you mean here? Perhaps I could have written more about it in the blog post, but sitting the language service atop the Roslyn Workspace layer is critical work that: 1. Gives F# a "modern" editor experience out of the box. 2. Gives F# an entry point into the large amount of Roslyn-based IDE features. Workspaces are how they "talk" to the language, so that means that they can now "talk" to F# as well. This is not possible with tooling today. This also has another big impact: F# will be able to use the CPS-based project system that is being built for C# and VB right now: https://github.com/dotnet/roslyn-project-system https://github.com/dotnet/roslyn-project-system
- MichaelGG 10y ago
  Hmm, how much does this provide? Will this make, say, F# interactive competitive with C# interactive? (Which blew past it, despite F#'s near-decade lead.) I'm tentatively hopeful I suppose.