4 ms·

I definitely agree with you for tuples especially smaller tuples. As tuples get larger however performance can swing the other way. As someone who codes some F#

by akra 10y ago

I definitely agree with you for tuples especially smaller tuples. As tuples get larger however performance can swing the other way. As someone who codes some F# for my day job it seems that while tuples should be easier in a functional language like F# for backwards compatibility struct tuples will be more awkward to use than in C# 7. I think they should of just bit the bullet for tuples up to a certain size. For records and unions however I think the attribute is fine. Most of the time for types of more than 3 fields say structs can be worse in performance than classes anyway. Records and unions tend to be assigned more and live longer than tuples most of the time. For unions for obvious reasons structs are not recursive in nature which with unions is required somewhat (see https://msdn.microsoft.com/en-us/library/ms229017%28v=vs.110%29.aspx https://msdn.microsoft.com/en-us/library/ms229017%28v=vs.110...). Definitely wouldn't want structs to be the default here.

MichaelGG 10y ago
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.

by akra 10y ago

MichaelGG 10y ago

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.