Allow fixed ref function parameters

[sweemer]

Currently structs passed by value have a fixed location within the scope of the function, and their address can be taken without using a fixed statement as shown in F1 below.

The address may also be passed to other functions and dereferenced without using an additional fixed statement, as shown in F2 below.

However, if the struct is passed by ref to another function, an additional fixed statement is needed in order to avoid a compiler error, as shown in F3 and F4 below.

I would like to propose fixed ref parameters, which allow passing by ref from an already fixed location without an additional fixed statement. Attempting to pass from an unfixed location would result in a compiler error.

I believe that passing by fixed ref is superior to passing by pointer because it preserves the syntax of pass by value, similar to how passing by const& in C++ is generally preferred to passing by pointer.

using System.Text;

public unsafe struct S
{
    public fixed byte bytes[10];
}

public class C
{
    public unsafe void F1(S s)
    {
        Encoding.ASCII.GetString(s.bytes, 10); // OK
    }

    public unsafe void F2(S* s)
    {
        Encoding.ASCII.GetString(s->bytes, 10); // OK
    }

    public unsafe void F3(ref S s)
    {
        Encoding.ASCII.GetString(s.bytes, 10); // compiler error CS1666
    }

    public unsafe void F4(ref S s)
    {
        fixed (byte* b = s.bytes)
        {
            Encoding.ASCII.GetString(b, 10); // OK
        }
    }

    public unsafe void F5(fixed ref S s) // my proposal would make this valid
    {
        Encoding.ASCII.GetString(s.bytes, 10);
    }
}

[huoyaoyuan]

This is not how modern C# using buffers. Instead, ref struct are used for representing buffers on stack. Moreover, the struct containing buffer bytes shouldn't being passed, but the Span referring to the buffer. The fields of ref struct are already considered as fixed.

[sweemer]

Hi @huoyaoyuan I totally agree that one should use ref struct in modern C#. The problem is that sometimes C# code has to interface with premodern C code, in which case ref struct cannot be used. As long as native interop is supported in C# then fixed buffers cannot be dismissed as the "wrong" way of doing things, and I still think that this proposal will help to slightly improve the expressiveness of interop in C#.

[huoyaoyuan]

fixed is more a concept at usage site and not meant to be passed through.

As long as native interop is supported in C# then fixed buffers cannot be dismissed as the "wrong" way of doing things

Inline array is the replacement. Actually in the implementation detail, fixed buffer is just a combination of an inline array type declaration and field declaration of that type. Moreover, pinning is often not required when spans are used.

Even if the old fashioned fixed buffer is used, pointer is not necessary. For both managed usage and native interop, span can be used as a replacement of pointer since LibraryImport generator has support for getting pointer from a span.

Even if pointer has to be used, it's not meaningful to pass the fixed state around. It's recommended to pin a variable at the lowest possible scope. Pinning twice is not a problem at all.

Reducing a line of code for pinning doesn't worth for the huge change of type mechanism. Moreover, the official source generator has already have the ability to pin things for you at the lowest P/Invoke site.

[sweemer]

Inline array is the replacement.

Inline arrays are new to me, so pardon my ignorance, but how can they be the replacement to fixed buffers if InlineArrayAttribute only works on structs with a single field? What about structs with more than one field?

For both managed usage and native interop, span can be used as a replacement of pointer since LibraryImport generator has support for getting pointer from a span.

Thanks for the info, I will look more into this and see if it works for my use case.

Pinning twice is not a problem at all.

The problem is that it's redundant, which admittedly is not a major problem, but incremental improvements in expressiveness and consistency are what make C# the great language that it is.

the huge change of type mechanism

Again pardon my ignorance, but how is this a huge change? As mentioned in my original post, it seems to me that the compiler should be able to track whether a struct passed by ref is already at a fixed location or not. I'm not proposing a change to the type system - just allowing the existing type info to flow through to the callee scope.

the official source generator has already have the ability to pin things for you at the lowest P/Invoke site.

Right, but as mentioned, the problem appears when the already pinned struct is passed to another function.

[CyrusNajmabadi]

but how can they be the replacement to fixed buffers

You define the inline array of the correct size, then embed an instance of that type in your final type.

[sweemer]

OK, I can't say I'm a fan of defining tons of single-member structs for all the possible fixed buffer lengths in my app, but I'll accept that this is the way forward.

To make the transition easier for apps that currently use fixed-sized buffers, I'm going to request to the Roslyn team that a code analysis warning and auto-fix be implemented.

[En3Tho]

FixedRef is rather an annotation/type concept - simply an indicator that this value can be safely converted to a pointer and used in a non gc-aware place.

You can define your own ref struct that represents this concept. I dont think language change is warranted here.

With upcoming roles/shapes/extensions/whatever I believe you can even use an "alias" instead of a real struct.