mutable on any binding

[Happypig375]

I propose we allow any pattern binding to be mutable.

let f (mutable d : System.Collections.Generic.Dictionary<int, int>) = // mutable parameter bindings
    for KeyValue (mutable k, mutable v) in d do
        // use k and v in an imperative algorithm...
        v <- v + 1

The existing let mutable x = syntax is equivalent to let (mutable x) =. Self identifiers should not be allowed mutable to be consistent with C#.

The existing way of approaching this problem in F# is to do an explicit copy.

let f (d : System.Collections.Generic.Dictionary<int, int>) =
    let mutable d = d // here
    for KeyValue (k, v) in d do
        let mutable k = k // here
        let mutable v = v // here
        // use k and v in an imperative algorithm...
        v <- v + 1

This is undesirable for large structs which could have avoided an unnecessary copy.

Pros and Cons

The advantages of making this adjustment to F# are

1. Less boilerplate
2. More optimization opportunities

The disadvantage of making this adjustment to F# is the encouragement of using mutables in a functional programming language. However, F# is multi-paradigm, and we use imperative programming where suitable, right?

Extra information

Estimated cost (XS, S, M, L, XL, XXL): S

Related suggestions: (put links to related suggestions here)

Affidavit (please submit!)

Please tick these items by placing a cross in the box:

• This is not a question (e.g. like one you might ask on StackOverflow) and I have searched StackOverflow for discussions of this issue
• This is a language change and not purely a tooling change (e.g. compiler bug, editor support, warning/error messages, new warning, non-breaking optimisation) belonging to the compiler and tooling repository
• This is not something which has obviously "already been decided" in previous versions of F#. If you're questioning a fundamental design decision that has obviously already been taken (e.g. "Make F# untyped") then please don't submit it
• I have searched both open and closed suggestions on this site and believe this is not a duplicate

Please tick all that apply:

• This is not a breaking change to the F# language design
• I or my company would be willing to help implement and/or test this

For Readers

If you would like to see this issue implemented, please click the 👍 emoji on this issue. These counts are used to generally order the suggestions by engagement.

[Tarmil]

Allowing mutable in patterns might be confusing, giving the false impression that it is a mutable reference into the object being matched.

match myArray with
| [| mutable x |] when x = 1 ->
    x <- 2
    printfn $"{myArray[0]}" // prints 1; one might reasonably have expected 2
| _ -> ()

[Happypig375]

@Tarmil a person thinking that is conflating byref with mutable. Has let mutable x = array[0] ever confused anyone?

[Happypig375]

This suggestion might also extend to other syntaxes like use:

let f (use d : IDisposable) = // automatic disposal
    // make use of d...

instead of

let f (d : IDisposable) =
    use _ = d // this line is awkward because it's assigning to a discard
    // make use of d...

[jwosty]

Interestingly, you can already combine let mutable and patterns:

let f (foo: int * int) =
    let mutable x, y = foo
    x <- ...
    y <- ...
    // ...

or for another example:

let f (foo: KeyValue<int,int>) =
    let mutable (KeyValue(k,v)) = foo
    k <- ...
    v <- ...
    // ...

So one could argue that it's at least consistent to allow mutable on the top level of certain, specific constructs like use and for and not pattern matching in general.

Though I will admit, anecdotally I've never personally found myself needing this (and I've written performance-sensitive F#).

I would suspect that the JITter is capable of optimizing the unnecessary struct copies away in most of these cases anyway, though maybe I am completely wrong -- can you provide an example where it fails to do so?