How does F# deal with the thousands of standard mutable types in the BCL?

Question

Like Point, Size, etc value types.

I also heard strings in .NET aren't truly immutable. Does F# use these or alternative immutable versions of them?

If it uses the standard mutable BCL types, would this not compromise the whole immutability trust that F# gives both at compile and runtime?

EDIT: What I meant to ask was, if you have alternative immutable versions of these BCL types, so I don't have to write all these various BCL types from scratch. Or is it the desired behavior that these types (like Point, Size, etc) are still mutable when using WinForms or whatnot?

Answer 1

The great thing about F# is that you are not forced to make everything immutable. This means you can write code functionally at first but if you find you need more performance you can also write imperative code.

So to answer your question: It deals with them just fine.

Answer 2

You can use the keyword mutable to use muttable data structures em F#. F# is not a pure functional language.

Answer 3

You can use types from the .Net BCL (base class library) just fine from F#. Many of these types are mutable, and thus come with all the associated costs and benefits of mutable data.

While one could choose to redesign and implement immutable versions of each of these mutable classes, that's often too much work. Immutability can be a spectrum, not just all or nothing, so you'll often have some of the core bits of your algorithm and data structure be immutable, but then use mutability when interacting with various .Net APIs that make it easy to talk to web services, or draw UIs, or whatnot.

That said, the F# runtime (FSharp.Core.dll) does include a few immutable collection classes like list, Set and Map (which, roughly, are immutable counterparts to the List, HashSet, and Dictionary classes found in System.Collections.Generic), since it is often useful to have immutable collections, e.g. for persistent snapshots in multi-threaded code.

From a 'mindset' point of view, I like to think of it as: F# encourages mutable state minimization. Almost every significant app is bound to use some mutable state, but if you keep your core data structures and algorithms mostly free of mutable state, then you get the benefits of immutability for the core part of your code. F# makes it easier to get this benefit at the core of your code, while still making it easy to add mutable state, either in scoped 'pockets', or around the edges and communication boundaries of your application.