System.Runtime.InteropServices.MemoryMarshall.Write with in parameter

[dzmitry-lahoda]

Current:

public static void Write<T>(Span<byte> destination, ref T value)
where T : struct

Proposed:

public static void Write<T>(Span<byte> destination, in T value)
where T : struct

Code example:

var readonlySpan = new ReadOnlySpan<byte>(new byte[1]);
var span = new Span<byte>(new byte[1]);
// assume in does not copy struct
// assume Write does not try to modify struct
MemoryMarshal.Write(span, in readonlySpan[0]); 

[stephentoub]

This would be a breaking change as defined. Such an overload can't be added because you can't overload on ref vs in, and the existing signature can't be changed from ref to in, as it would break call sites using ref.

[AaronRobinsonMSFT]

@stephentoub Is this at all possible in your mind? Should we close this issue?

@dzmitry-lahoda Do you have any further suggestion here? Does what @stephentoub wrote make sense to you?

[dzmitry-lahoda]

I have checked IL and it seems changing ref to in is incompatible on binary level(i.e. in compiled assemblies)? So not only compilation will fail, but runtime, I guess. Issue may be closed. My workaround - start writing unsafe code to get readonly API now lacking as part corefx API, which seems where done before in and readonly where invented. I just wanted to make our stack to be type safe - i.e. types say what can and cannot be done in terms of mutability.

[stephentoub]

I don't think there's a binary-breaking change impact, as long as we're talking about static/non-virtual methods. But there's definitely a source-breaking change. We've been discussing whether the language could be relaxed here a bit, to allow ref at call sites when a method takes in, but it has a potential impact on overload resolution, which is always something that's fraught with complexity and taken very seriously. If something changes there in the future, we can review all of the places we take ref to see whether it would warrant a change to in; for now, though, this isn't really actionable and should be closed. @dzmitry-lahoda, thanks for raising the issue.

[dzmitry-lahoda]

So workflow of developers will be:

• decompile Unsafe and MemoryMarshall or grab IL code generated-written from corefx
• put into Nuget package called Unofficial.....MemoryMarshall`` (may be other classes I will hit to use).
• use

Notes

• other languages which do no know about in will see ref anyway
• F# and C# seems (only languages I use) do understand in on source level
• CLR seems have no in on binary level, only ref

[jkotas]

@dzmitry-lahoda There is a official System.Runtime.CompilerServices.Unsafe package: https://www.nuget.org/packages/System.Runtime.CompilerServices.Unsafe/ . I do not see why you would need to create unofficial version of it.

The official System.Runtime.CompilerServices.Unsafe package has public static partial class Unsafe { public static ref T AsRef<T>(in T source); } method that allows you to cast away the readonliness in case you need to call method that takes readonly ref, but that does not have ref marked as readonly.

[dzmitry-lahoda]

@jkotas, may be i read documentation wrong or documentation is stale, not sure. But as of now documentation looks like broken.

public static TTo As<TFrom,TTo> (ref TFrom source);
public static ref T AsRef<T> (ref T source);
public static T Subtract<T> (ref T source, int elementOffset);

I have cloned corefx couple month ago, and see in Unsafe.cs:

        public static T ReadUnaligned<T>(ref byte source) { throw null; }

Not sure why this (and other methods) do require ref, while could be in.

[jkotas]

public static ref T AsRef<T> (ref T source)

Yes, this wrong. It should be public static ref T AsRef<T> (in T source). Submitted dotnet/dotnet-api-docs#1968 to update the docs.

Not sure why this (and other methods) do require ref

It is for the same reason MemoryMarshal.Write has ref in the signature. These methods were introduced before the C# readonly/in feature was invented.

[dzmitry-lahoda]

Thanks. I understand. And looks not so well for me. I am trying to push types to the max in entity component system data-oriented design of networked first-person shooter game. While retaining sanity of what can do what with a small boilerplate as possible. So I use all new features attached to in, readonly, ref, and also interfaces with implementions, Unsafe, Memory, Buffers, constrained generics (Rust?). An important part of work is to put in into a readonly code to allow me and my colleagues to judge by an interface. Unfortunately, when I got into old API(and some C# language decisions to favor CLR indifference to ref kinds) I am forced to replace in with ref along with all the call stack. And because some tools we use also forced with ref, while could be in, than forkin corefx API is the way (and patching third-party code we use).