We have API in System.Runtime that accepts params ReadonlySpan. Normally we'd be able to consume any API in System.Runtime with just a reference to System.Runtime - but calling these new APIs demands System.Runtime.InteropServices.MemoryMarshal.CreateReadOnlySpan
I wonder if we should push this type down, perhaps others in System.Memory as well. It's implementation already lives in System.Private.CoreLib
Reproduction Steps
Here's a repro that demonstrates a customer scenario where they do runtime compilation and specify System.Runtime only as a reference. This isn't too farfetched since we recommend that folks use reference assemblies.
Description
We have API in System.Runtime that accepts params ReadonlySpan. Normally we'd be able to consume any API in System.Runtime with just a reference to System.Runtime - but calling these new APIs demands
System.Runtime.InteropServices.MemoryMarshal.CreateReadOnlySpan
I wonder if we should push this type down, perhaps others in System.Memory as well. It's implementation already lives in System.Private.CoreLib
Reproduction Steps
Here's a repro that demonstrates a customer scenario where they do runtime compilation and specify System.Runtime only as a reference. This isn't too farfetched since we recommend that folks use reference assemblies.
compileSR.zip -> derived from https://learn.microsoft.com/en-us/archive/msdn-magazine/2017/may/net-core-cross-platform-code-generation-with-roslyn-and-net-core#executing-code-the-emit-apis sample
Expected behavior
Comple successful and output "Hello World!!!"
Actual behavior
Regression?
Yes, the addition of the params ReadOnlySpan overloads introduced this break.
Known Workarounds
Add a reference to System.Memory
Configuration
No response
Other information
See https://github.com/dotnet/sdk/pull/41014 for some background. CC @333fred @jaredpar @Jozkee