Make it illegal to pass a temporary ref-cell as byref

[0x53A]

I propose we ... Make it illegal to pass a temporary ref-cell as byref

related

(see https://github.com/Microsoft/visualfsharp/pull/5542)

With the F# 4.5 work, the following previously compiling code errors out:

type Incrementor(delta) =
    member this.Increment(i : byref<int> ) = i <- i + delta     
let kvp = KeyValuePair(1, 2)
incrementor.Increment(&kvp.Value)

the reason is that this does not take the address of .Value (which is a property), but instead copies it into a temporary local and takes the address of that local.

suggestion

I suggest to do the same for the pattern

type Incrementor(delta) =
    member this.Increment(i : byref<int> ) = i <- i + delta     
let i = 1
incrementor.Increment(ref i)

Everyone who isn't intimately familiar with ref-cells would expect the above code to mutate i. Instead it allocates a temporary ref-cell and takes the address of that.

It desugars to: incrementor.Increment(&({contents=x}.contents@)) (where contents@ is the backing field for the property)

Especially for people coming from C#, the difference between ref and & is confusing, doubly so because & is equivalent to the ref keyword in c#.

Note that the following code would still be legal, because ref-cells are just normal values which I can pass around:

let f (x: int ref) = () // this receives a ref-cell, not a byref
let i = 1
f (ref i)

Pros and Cons

The advantages of making this adjustment to F# are ... 99.99% of occurrences of this pattern are bugs. I am tempted to say 100% but some people write horrible code.

The disadvantages of making this adjustment to F# are ... it's a breaking change

Extra information

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

Related suggestions: (put links to related suggestions here)

Affidavit (please submit!)

Please tick this by placing a cross in the box:

• [x] This is not a question (e.g. like one you might ask on stackoverflow) and I have searched stackoverflow for discussions of this issue
• [x] I have searched both open and closed suggestions on this site and believe this is not a duplicate
• [x] 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.

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

[zpodlovics]

An interesting question to the language designers / developers: why the ref<'T> = byref<'T> equivalence even created in the first place?

[cartermp]

Agreed on the weird equivalence between ref and byref that must have been implemented long ago. It's something I'd like to do away with somehow, but I do fear how much of a break that could be.

[dsyme]

Agreed on the weird equivalence between ref and byref that must have been implemented long ago. It's something I'd like to do away with somehow, but I do fear how much of a break that could be.

Agreed