F# struct member referencing 'this' results in an error

Question

New F# developer, long time C# developer. As an exercise in learning F#, I'm working my way through Eric Lippert's series on graph coloring translating from his C# to F#. I'm currently working on part two.

The original C# is in the blog post - here's the F# translation so far - but it doesn't compile:

type BitSet = struct
        val bits : int
        private new(b) = { bits = b }

        static member Empty = BitSet(0)

        member this.Contains (item:int) = (this.bits &&& (1<<< item)) <> 0
        member this.Add (item:int) = BitSet(this.bits ||| (1 <<< item))
        member this.Remove (item:int) = BitSet(this.bits &&& ~~~(1<<<item))
        member this.Bits = seq {
                for item in 0..31 do
                    if this.Contains(item) then
                        yield item
            }
    end

This produces the very mysterious error "error FS0406: The byref-typed variable 'this' is used in an invalid way. Byrefs cannot be captured by closures or passed to inner functions" from the definition of Bits:seq<int>.

Curiously, changing the keyword "struct" to "class" results in valid code. Coming from a C# perspective, this seems like nonsense, but I'm sure there's a valid reason behind it. The question is - how should I write the Bits function? What's the underlying F# principle that I need to understand for this to make sense?

Answer 1

I think the problem is that the this reference is created as a reference to the current value of the struct, so that you can modify the struct (if you wanted and the struct was mutable).

This causes problem inside seq { .. } because this generates code inside another class and so the compiler fails to pass the reference to the "this" instance.

If you assign the this value an ordinary local variable, then the code works fine:

member this.Bits = 
    let self = this
    seq {
        for item in 0..31 do
            if self.Contains(item) then
                yield item
     }

As a matter of style - I would probably use an implicit constructor, which makes the code a bit shorter. I also prefer the Struct attribute over the explicit struct .. end syntax, but both of these are just a matter of style (and I'm sure others will have different preferences). You might find it useful just as an alternative or for comparison:

[<Struct>]
type BitSet private (bits:int) = 
    static member Empty = BitSet(0)
    member this.Contains (item:int) = (bits &&& (1<<< item)) <> 0
    member this.Add (item:int) = BitSet(bits ||| (1 <<< item))
    member this.Remove (item:int) = BitSet(bits &&& ~~~(1<<<item))
    member this.Bits = 
        let self = this
        seq {
            for item in 0..31 do
                if self.Contains(item) then
                    yield item
        }

Answer 2

this means something different for struct vs class since they are represented differently in memory. C# is glossing over the details and making it work while F# is deciding you need to handle the difference yourself.

The correct solution is to cache the values you care about in local variables to avoid trying to use this in the seq block. You can either cache the whole object as Tomas shows or just cache the bits value and inline the Contains call.

Answer 3

To address your point here:

This produces the very mysterious error "error FS0406: The byref-typed variable 'this' is used in an invalid way. Byrefs cannot be captured by closures or passed to inner functions" from the definition of Bits:seq. Curiously, changing the keyword "struct" to "class" results in valid code. Coming from a C# perspective, this seems like nonsense

This should not seem like nonsense from a C# perspective. Here:

struct Mutable
{
  public int x;
  public void DoIt()
  {
    Action a = () => {
      this.x = 123;
    };
  }
}

You'll get the same error in that program, along with the helpful advice that you could capture the "this" by value by copying it to a local.

This is a consequence of three facts: first that this in a struct S is of type ref S, not S, second, that variables, not values, are captured, and third, that the .NET type system does not allow storage of ref variables on the long term storage pool, aka the GC'd heap. Refs can only go on the short term storage pool: stack or registers.

Those three facts together imply that you can't store this in a struct in any way that could survive longer than the activation, but that is precisely what we need when creating a delegate; the delegate will be on the long term pool.