Tagging subscribers to this area: @dotnet/area-system-runtime-compilerservices
See info in area-owners.md if you want to be subscribed.

@tannergooding FYI - marked this one ready for review since it seems to be minor addition to past work.

Video

• Looks good as proposed

namespace System.Runtime.CompilerServices
{
    public static class Unsafe
    {
-       public static void* AsPointer<T>(ref T value);
+       public static void* AsPointer<T>(ref readonly T value);
    }
}

Risks
None. Unsafe.AsPointer is already an unsafe API, and it's in an unsafe namespace. This API makes things simpler, but developer could already achieve the same, just by adding an Unsafe.AsRef call on top of this chain. Just updating the signature for AsPointer simplifies all callsites instead.

IMO this makes an unsafe api even more unsafe since it implicitly converts an immutable ref to a mutable where previously developer had to state that with AsRef. Should we continue making unsafe code more convenient to write? PS: I'm not against this change, just hoping we won't continue in this direction

I don't see how it's really any different to allowing &myLocalOfStructType.ReadonlyField (which gives a pointer, which is therefore mutable)

Right, this was covered in API review a bit.

The reason this one is "ok" is because the point of AsPointer<T>(...) is to go from a byref to a pointer without pinning and going directly from a ref readonly T or a in T to a void* via pinning is already allowed.

We don't want to do this for things like Add because that would be two levels of unsafety that isn't already trivially possible. We'd rather want some kind of "matched mutability" concept so we can say if the input is ref readonly the output is ref readonly, but if the input is ref the output is ref.

<permission P> when??? 👀 /s