Support ref structs in generics

[vzarytovskii]

.NET 9 will support ref structs in generics as well as new constraint.
A bunch of new APIs will be utilising it, hence it needs to be supported in F#

Runtime support: dotnet/runtime#65112
C#: https://github.com/dotnet/csharplang/blob/main/proposals/ref-struct-interfaces.md

Note: only consuming is in scope, everything else isn't possible right now, due to lack of many ref-related features support in compiler (ref fields, escape analysis as examples).

[brianrourkeboll]

Note: only consuming is in scope, everything else isn't possible right now, due to lack of many ref-related features support in compiler (ref fields, escape analysis as examples).

It's probably worth keeping in mind this feature's potential usefulness in someday addressing things like fsharp/fslang-suggestions#688, fsharp/fslang-suggestions#805, fsharp/fslang-suggestions#887, fsharp/fslang-suggestions#1140, #7828.

[vzarytovskii]

Note: only consuming is in scope, everything else isn't possible right now, due to lack of many ref-related features support in compiler (ref fields, escape analysis as examples).

It's probably worth keeping in mind this feature's potential usefulness in someday addressing things like fsharp/fslang-suggestions#688, fsharp/fslang-suggestions#805, fsharp/fslang-suggestions#887, fsharp/fslang-suggestions#1140, #7828.

Yes, however this feature only covers consuming such constraints, and give possibility to interact with such APIs, everything else is separate and will require additional work around byrefs and byref-likes in compiler (around escape analysis, supporting ref fields, scoped refs, unscoped refs, etc).

[brianrourkeboll]

Yep, I understand.

I just meant that we should try to ensure that whatever approach is taken to add support for consumption doesn't limit our options if we also someday wanted to support production, or that thinking about the latter might have the potential to inform some aspects of how the former is done.

[brianrourkeboll]

(Let me know if you'd rather I delete this here and wait to comment on the RFC.)

...The reason I linked those specific issues in #16800 (comment) is that they present concrete scenarios where using this feature productively might be useful.

For example, do we plan to surface the new constraint in the type signature when a construct using the constraint defined in C# is consumed by F# code?

Even if we don't plan to allow producing such a constraint in F# for now, thinking about what that might look like might inform how we represent such a signature, e.g., consider:

let inline (|>) x (f : 'a -> 'b when :? byref<'a> and 'a :? struct) = f x

type SomeBuilder () =
    member inline _.Bind (x, [<InlineIfLambda>] f : 'a -> M<'b> when :? byref<'a> and 'a :? struct) = …

— which would be analogous to the C# —

public static B op_PipeRight<A, B>(A x, Func<A, B> f) where A : allows ref struct => f(x);

public class SomeBuilder
{
    public M<B> Bind<A, B>(M<A> x, Func<A, M<B>> f) where A : allows ref struct { … }
}

— etc.

Using :? for "might be" immediately strikes me as one potential way to naturally represent allows in F#, by the same logic that we already use : for "is" and :> for "is convertible to" in both the grammar of types and the grammar of expressions.