[API Proposal] Allow easier access to binary representation of blittable types

[GrabYourPitchforks]

Occasionally advanced developers may have a need to view the binary representation of a blittable value type. For instance, the UTF-8 parsers and formatters have the need to treat a GUID as a sequence of binary data so that it can be efficiently inspected and converted to wire format. This currently involves using pointers and reinterpreting casts, or it involves the use of Unsafe.As<,>, or it involves creating a temporary Span<byte> so that the value can be copied directly into that buffer for future inspection. The framework currently lacks a copyless, type-safe API for performing this operation.

Proposal

Add a new single method to the existing MemoryMarshal class.

public static class MemoryMarshal {
    public static Span<byte> Blit<T>(ref T value) where T : struct;
}

This is very similar to the existing BinaryPrimitives.WriteMachineEndianness<T>(Span<byte> buffer, ref T value) method. The key difference is that the existing WriteMachineEndianness method copies the contents of a blittable struct to an existing Span<byte>, whereas the new method being proposed is a zero-copy API that simply presents a binary data view over an existing blittable struct.

Alternatively, if this method does not belong on the MemoryMarshal class, the BinaryPrimitives class could be a useful home for it.

I do not believe this method belongs on the Unsafe class. Even though the method itself is implemented in terms of unsafe code, it's intended to be presented as a type-safe facade since it fails if the requested type is not blittable. (This method could be used to circumvent visibility, just like other methods on BinaryPrimitives, but it can't be used to stomp on arbitrary object references.)

A sample implementation of this function is provided at the reference below.
https://github.com/GrabYourPitchforks/corefx/blob/e30a8cca02b26b7116fc85f7d4e47bcfab1fe514/src/System.Memory/src/System/Buffers/Text/Utf8Formatter/FormattingHelpers.cs#L32-L55

[jkotas]

It is not possible to implement this API with slow Span. This API can only exist with fast Span.

[GrabYourPitchforks]

Ugh, that's unfortunate. :(

[benaadams]

Would there be value in having it as a platform api? (netcoreapp2.1, net47x, e.g non-netstandard)

[ahsonkhan]

Regarding the name, how about BitBlit to be more explicit since blitting is a relatively esoteric concept, imo, and the wikipedia page even suggests going to BitBlit:

• https://en.wikipedia.org/wiki/Blit
• https://softwareengineering.stackexchange.com/questions/181312/is-there-a-synonym-for-blittable-that-is-more-common

[tannergooding]

This specifically calls out "blittable" types, but does it actually refer to "unmanaged" types instead?

[jkotas]

The API for Snap<byte>->ref reinterpretation is called AsRef (#30613).

This is API the ref->Snap<byte> reinterpretation (other direction). Would it make sense to call it AsSpan to follow the pattern?

[ektrah]

Isn't this equivalent to turning a ref T into a Span<T> followed by Cast<T, byte>? I thought turning a ref T into a Span<T> is not possible, even with fast span.

[jkotas]

I thought turning a ref T into a Span is not possible, even with fast span.

It is possible using MemoryMarshal.CreateSpan API. Note that all APIs on MemoryMarshal are unsafe API. You have to be careful to not create a dangling pointer when using this API.

[ektrah]

Is AsSpan<T> followed by Cast<T, byte> an option then?

public static Span<T> AsSpan<T>(ref T value) where T : struct;

[ahsonkhan]

This is API the ref->Snap<byte> reinterpretation (other direction). Would it make sense to call it AsSpan to follow the pattern?

How about AsBytes, similar to the existing overloads:

public static System.Span<byte> AsBytes<T>(System.Span<T> span) where T : struct { throw null; }
public static System.Span<byte> AsBytes<T>(ref T value) where T : struct { throw null; }

[terrajobst]

Video

Isn't this equivalent to turning a ref T into a Span<T> followed by Cast<T, byte>? I thought turning a ref T into a Span<T> is not possible, even with fast span.

Right. Thus we don't believe we need a dedicated API for this. Yet.