[API Proposal]: {ReadOnly}Span(ref T) constructor

[stephentoub]

Background and motivation

As part of the C# 11 work to enable ref fields, it will be safe to create a {ReadOnly}Span from a ref (with an implicit length of 1), because the compiler will track the lifetime of the ref and ensure the created span can't outlive it. Creating spans for a single item is quite common, and we should have public constructors for this situation.

This has been proposed by others offline... I agree with it and am just opening the issue for it so we can make forward progress on it.
cc: @jaredpar, @AaronRobinsonMSFT, @tannergooding

API Proposal

namespace System
{
    public ref struct Span<T>
    {
+        public Span(ref T reference);
    }

    public ref struct ReadOnlySpan<T>
    {
+        public ReadOnlySpan(in T reference);
    }
}

API Usage

int i = ...;
CallMethodThatTakesASpan(new ReadOnlySpan<T>(in i));

Alternative Designs

No response

Risks

No response

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

Issue Details

---

Background and motivation

As part of the C# 11 work to enable ref fields, it will be safe to create a {ReadOnly}Span from a ref (with an implicit length of 1), because the compiler will track the lifetime of the ref and ensure the created span can't outlive it. Creating spans for a single item is quite common, and we should have public constructors for this situation.

This has been proposed by others offline... I agree with it and am just opening the issue for it so we can make forward progress on it.
cc: @jaredpar, @AaronRobinsonMSFT, @tannergooding

API Proposal

namespace System
{
    public ref struct Span<T>
    {
+        public Span(ref T reference);
    }

    public ref struct ReadOnlySpan<T>
    {
+        public ReadOnlySpan(ref T reference);
    }
}

API Usage

int i = ...;
CallMethodThatTakesASpan(new ReadOnlySpan<T>(ref i));

Alternative Designs

No response

Risks

No response

Author:	stephentoub
Assignees:	-
Labels:	area-System.Memory, untriaged, api-ready-for-review
Milestone:	7.0.0

[stephentoub]

Examples for all the places in corelib where we create length-1 spans around a single reference are in #67447.

[jaredpar]

public ReadOnlySpan(ref T reference);

Believe this should be in T reference

[stephentoub]

Fixed

[Sergio0694]

Is this (the ReadOnlySpan<T> constructor) meant to be shipped with an analyzer to disallow rvalue-s as previous discussed for similar cases? Otherwise this would allow eg. new ReadOnlySpan<int>(5), or creating one from a by-value return of some API, with the span actually just pointing to a hidden copy of the value. Unless allowing this is by design, or just not a concern? 🤔

[stephentoub]

That's why I'd gone with ref (that, and more generally I really dislike not having to specify that the thing you're passing in is being passed by ref, e.g. I wish you had to write new Span<T>(in value) instead being allowed to write new Span<T>(value)), but I don't care enough to fight about it, and I realize using ref blocks certain valid usage (i.e. where you already have an in you want to wrap). If you pass in an rvalue, you get what you get I guess.

[jaredpar]

Otherwise this would allow eg. new ReadOnlySpan(5), or creating one from a by-value return of some API, with the span actually just pointing to a hidden copy of the value. Unless allowing this is by design, or just not a concern?

This is explicitly supported by the language hence it doesn't pose a safety concern.

and more generally I really dislike not having to specify that the thing you're passing in is being passed by ref, e.g. I wish you had to write new Span(in value) instead being allowed to write new Span(value)

That is something that we can consider adding to the language. One simple idea that came to my mind as I was reading this is allowing two syntaxes on parameters:

• in: means what it means today
• ref readonly: provides a warning at the call site when parameter is not an lvalue but otherwise acts like an in parameter

Could also tweak the second idea to be an error but then you're removing your ability to upgrade existing APIs.

[AaronRobinsonMSFT]

ref readonly: provides a warning at the call site when parameter is not an lvalue but otherwise acts like an in parameter

+1

[tfenise]

Why is public Span(in T reference); also in?