[RFC FS-1081 Discussion] - Extend fixed expressions

[jwosty]

Discussion for RFC FS-1081

Suggestion here: fsharp/fslang-suggestions#761

[abelbraaksma]

The proposal explicitly states that the fixed statement is going to support any byref<'t> and any type that implements GetPinnableReference: unit -> byref<'t>.

The motivation seems to be that this is the same as C#. However, that's not precisely so. C# also supports GetPinnableReference: unit -> inref<'t> with fixed. For instance, here inref<'t> is the result-type of ReadOnlySpan.GetPinnableReference.

I think we should include that case. It also makes sense, because we already support fixed with inref<char> w.r.t. to string: use x = fixed myStr, where GetPinnableReference on string returns inref<'t>.

This brings up another topic: currently, in F#, you can read/write to whatever fixed returns, regardless whether it was an inref or byref. This issue comment (dotnet/runtime#36989 (comment)) suggests that the Runtime team is trying to limit the ways that read-only memory (including strings) can be modified. However, we just introduced a simple of doing that through fixed.

This is probably going to stay that way, unless there's a way we can let fixed issue a warning of some sorts when used with read-only memory. Btw, even if we flat out forbid fixed with read-only memory, you can still use MemoryMarshal.CreateSpan on a ReadOnlySpan (as in: if you want to wreak havoc on strings, you can).

[jwosty]

Made a PR to reflect these finer points (#743).

This brings up another topic: currently, in F#, you can read/write to whatever fixed returns, regardless whether it was an inref or byref. This issue comment (dotnet/runtime#36989 (comment)) suggests that the Runtime team is trying to limit the ways that read-only memory (including strings) can be modified. However, we just introduced a simple of doing that through fixed.

This is probably going to stay that way, unless there's a way we can let fixed issue a warning of some sorts when used with read-only memory. Btw, even if we flat out forbid fixed with read-only memory, you can still use MemoryMarshal.CreateSpan on a ReadOnlySpan (as in: if you want to wreak havoc on strings, you can).

Right, unfortunately I don't think we can do anything about that. C#'s behavior is the same.

[jwosty]

[abelbraaksma]

Sure! I'll do that ;)

[jwosty]

I appreciate it!

[jwosty]

I notice there's also an IPinnable interface (https://learn.microsoft.com/en-us/dotnet/api/system.buffers.ipinnable.pin?view=net-7.0) with Pin and Unpin methods. I think fixed should also support anything implementing that interface, too. Interestingly, C#'s fixed statement does not -- is there a reason why this would be a bad idea?

The following three classes implement IPinnable (and none of them have GetPinnableReference):

• Memory<T>
• ReadOnlyMemory<T>
• MemoryManager<T>

Supporting GetPinnableReference is still more important than IPinnable, because at least with the latter the user can call the methods manually. This actually presents a potential workaround for today for Span<T> + native code scenarios - it seems that if you can afford to use (or copy it to) a Memory<T> instead, you can use Pin and Unpin.

[jwosty]

@dsyme @KevinRansom @vzarytovskii thoughts? It really wouldn't be that hard to add this as well to the existing PR and I'd be happy to do so since I'm already digging around in there (dotnet/fsharp#15697)

[vzarytovskii]

We support ns20, which lacks the interface. We technically can try and find it in compile time (meaning we're targeting tfm which has it).

Need to look if we do that kind of conditional codegen/checking already for something else.

[jwosty]

I wonder if Span has special cases in the compiler, since it's only >= net standard 2.1?

[vzarytovskii]

I wonder if Span has special cases in the compiler, since it's only >= net standard 2.1?

It doesn't IIRC (unless I missed something).

[jwosty]

So it turns out it's in System.Memory, in all TFMs. Does that solve the problem?

[jwosty]

It's also interesting to note that fields are only sometimes allowed to be pinned. For example, the following is currently permitted:

type MyType = { mutable value: int }

module Point =
    let pin (thing: MyType) =
        use ptr = fixed &thing.value
        printfn "%i" (NativePtr.read ptr)

and

type MyType =
    val mutable value: int
    
    new() = { value = 42 }
    
    member this.Pin () =
        use ptr = fixed &this.value
        printfn "%i" (NativePtr.read ptr)
        ()

but this is not permitted:

type MyType() =
    let mutable value = 42
    
    member this.Pin () =
        use ptr = fixed &value
        printfn "%i" (NativePtr.read ptr)
        ()

I wonder if this is intentional? Shouldn't the 3rd example also work?

[jwosty]

Just noting that the PR fixes this (all of these now work).