Support `UnsafeAccessorAttribute`

[Lanayx]

I propose we support UnsafeAccessorAttribute to substitute reflection

This runtime feature is already supported by C# to give a performance boost compared to the reflection

Existing C# syntax:

private static class Accessors<T>
{
    [UnsafeAccessor(UnsafeAccessorKind.Field, Name = "_items")]
    public static extern ref T[] GetItems(List<T> list);
}

Suggested F# syntax:

module Accessors =
  [<UnsafeAccessor(UnsafeAccessorKind.Field, Name = "_items")>]
  extern byref<'T[]> GetItems(ResizeArray<'T> resizeArray)

Concrete Example
This code:

    let inline private getUnderlyingDict<'T> =
        let param = Expression.Parameter(typeof<'T>)
        let storeProp = Expression.Property(param, "Store")
        let getStoreExpr = Expression.Lambda<_>(storeProp, param)
        let getStore: Func<'T, Dictionary<string, StringValues>> = getStoreExpr.Compile()
        fun collection -> getStore.Invoke(collection)

    let formCollectionDict = getUnderlyingDict<FormCollection>
    let queryCollectionDict = getUnderlyingDict<QueryCollection>

can be substituted by this code:

    [<UnsafeAccessor(UnsafeAccessorKind.Method, Name = "get_Store")>]
    extern Dictionary<string, StringValues> formCollectionDict(FormCollection formCollection)
    [<UnsafeAccessor(UnsafeAccessorKind.Method, Name = "get_Store")>]
    extern Dictionary<string, StringValues> queryCollectionDict(QueryCollection queryCollection)

gaining both performance and readability

Related docs:

https://learn.microsoft.com/en-us/dotnet/fsharp/language-reference/functions/external-functions
https://learn.microsoft.com/en-us/dotnet/api/system.runtime.compilerservices.unsafeaccessorattribute
https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-9/#reflection
https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-10/#reflection
dotnet/runtime#81741

The existing way of approaching this problem in F# is using regular reflection

Concrete issues (per @Happypig375, see discussion):

1. extern functions don't support generic types
2. extern functions have an extraneous throw in implementation

Pros and Cons

The advantages of making this adjustment to F# are better performance in applicable cases

The disadvantages of making this adjustment to F# are don't see disadvantages

Extra information

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

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.

[T-Gro]

I am a little puzzled by the motivation - I thought this attribute exists in order to access private fields via source code, i.e. when source generators (or similar mechanism) is supported.
The attribute was added so that libraries have a migration path from doing reflection/Reflection.Emit over private data (previously), and would want to do the same from generated source code.

The context for introducing this attribute was the new presence of C# source gen.
I feel like the motivation should be different in their absence (in F#).

I think it is clear that this is extremely risky, error-prone and fragile way of doing things - so the bar for motivating this is high.

[Lanayx]

@T-Gro It was rather an explanation why using reflection in F# is important :) The motivation is just replacing even more error-prone code, that we have to write today. For example, in Oxpecker I use the following code to access private property:

    type DictionaryLikeCollection<'T
        when 'T :> IEnumerable<KeyValuePair<string, StringValues>>
        and 'T: (member Keys: ICollection<string>)
        and 'T: (member get_Item: string -> StringValues)
        and 'T: (member ContainsKey: string -> bool)
        and 'T: (member TryGetValue: string * byref<StringValues> -> bool)> = 'T

    let inline private getUnderlyingDict<'T when DictionaryLikeCollection<'T>> =
        let param = Expression.Parameter(typeof<'T>)
        let storeProp = Expression.Property(param, "Store")
        let getStoreExpr = Expression.Lambda<_>(storeProp, param)
        let getStore: Func<'T, Dictionary<string, StringValues>> = getStoreExpr.Compile()
        fun collection -> getStore.Invoke(collection)

    let formCollectionDict = getUnderlyingDict<FormCollection>
    let queryCollectionDict = getUnderlyingDict<QueryCollection>

It would look much nicer if UnsafeAccessor was available

[Happypig375]

The concrete reason why this syntax doesn't compile:

open System.Runtime.CompilerServices
module Accessors =
  [<UnsafeAccessor(UnsafeAccessorKind.Field, Name = "_items")>]
  extern byref<'T[]> GetItems(ResizeArray<'T> resizeArray)

is because of

error FS0010: Unexpected type application  in extern declaration. Expected identifier or other token.

It is a parser shortcoming for extern functions that generics are unsupported. Aside from this issue, the extern implementation of F# (compare: in C#) also contains a "extern was not given a DllImport attribute" throw directly in the method implementation for UnsafeAccessor external functions. This is a separate issue from parsing generic types in extern functions.

The parser shortcoming should deserve an approval since we can now have generic unmanaged structs and C# can use them in extern functions just fine ever since 2019.

It is just incorrect to frame a runtime feature as needing compiler support when the actual issues are:

• extern functions don't support generic types
• extern functions have an extraneous throw in implementation

which are wholly unrelated to any support needed for zero-cost reflection.

Zero-cost reflection is just one of the many use cases that fixing these two issues can enable.

[Lanayx]

@Happypig375 thank you for the detailed explanation! I understand that the original issues are different, however I think that this suggestion should stay, because those issues are quite low-level and it's hard to justify them separately, while current framing provides a tangible use case that can be presented to users as a standalone feature.

[T-Gro]

extern functions don't support generic types
-> approved in principle, as said this is missing now and helps other legit use cases in native interop

extern functions have an extraneous throw in implementation
-> this will need to be better specified, i.e. the type checking ruleset re-formulated

@Lanayx :
I still fail seeing this in the reflection category, this is IMO a clear source code category.
At design time, you know what type you want to read from, you even know the private property name you want to read (this alone makes it not "reflective").
You need this to bypass an accessibility check which was added there for a reason by the type's author. From code, not reflectively.

[Lanayx]

@T-Gro you are probably right, I've always unconditionally thought about access to private fields as a reflection, and this idea was supported by the performance articles where this attribute was put under Reflection topic. I think it's because doting this kind of tasks was only possible through reflection. I'll update the ticket description.

[T-Gro]

Will see how long it takes before someone comes with an idea to build a .NET-language-fork that simply ignores all access modifiers in interop scenarios, desugaring such access into UnsafeAccessor generated calls.