[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

[ghost]

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?

[jaredpar]

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

That should be ref otherwise it violates readonly rules

[stephentoub]

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

Editing in haste.

[tannergooding]

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:

Yes please. I would love this and it would solve one of the biggest issues I have with in (the other is changing a signature from ref to in is a source breaking change; if we allowed that for ref to ref readonly then its even better as we could update already shipped APIs).

[Sergio0694]

I've linked this issue in the proposal as well, but just to notify folks in here too - we now have an official proposal on csharplang for ref readonly parameters, which would help in scenarios such as this (as well as enabling us to "fix" the signature of lots of APIs we've shipped already, like Unsafe.Read, Vector128.LoadUnsafe, Volatile.Read, etc.). See dotnet/csharplang#6010.

[terrajobst]

• Looks good as proposed
• Once C# completed [Proposal]: ref readonly method parameters (VS 17.8, .NET 8) csharplang#6010, we should change the constructor for ReadOnlySpan<T> to use that instead.

namespace System;

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

[stephentoub]

(Just noting we should not expose these until the C# safety work is completed.)

[halter73]

Are there really safety concerns with passing an rvalue to the ReadOnlySpan constructor or is just inefficient? Does it basically just box the value?

[tannergooding]

Its not, IMO, a safety concern, but rather one of intent. Basically there are two considerations around readonly byrefs.

In one hand you have cases where it being a readonly byref is really an "implementation detail", it largely only exists as a perf optimization. Most of the places we use it in the BCL (or that you see const T& in C/C++) are similar.

On the other hand, you have cases where it being a readonly byref is a very important detail, generally because the API is directly dealing with the concept of memory. Consider for example Unsafe.IsNullRef(ref T). While there is nothing "conceptually" wrong with passing an rvalue here and Unsafe.IsNullRef(5) will do "the right thing". However, it's likely an error/mistake on the end of the consumer and is effectively a "pointless" API call to do because the answer is constant.

In the same way, Span and ReadOnlySpan are intentionally capturing and tracking the passed in byref. There is nothing conceptually wrong with new ReadOnlySpan(5), but it represents a potential error/problem case due to the API dealing explicitly with the concept of memory. The cases where a user might want an rvalue are cases like params ReadOnlySpan<T> and in that case other syntax should handle the creation of said span.

[stephentoub]

The safety work I was referring to above wasn't about rvalues; it was about the C# compiler tracking ref lifetime. If with the C# compiler today we were to expose these constructors, you could do:

public Span<int> DoNotDoThis()
{
    int i = 0;
    return new Span<int>(ref i);
}

the compiler would happily compile that, and it would be really bad.

[terrajobst]

the compiler would happily compile that, and it would be really bad.

I don't always peek into the stack, but when I do, I make sure it's into a stack frame that was unwound

[deeprobin]

Does this issue include changes in the JIT or VM or just exposing the private/internal constructors + appropriate tests?

[tannergooding]

This can't be implemented until the relevant language changes are in.

[jaredpar]

@deeprobin this issue just covers the API changes around Span / ReadOnlySpan. There are many other changes that need to happen to support ref fields. The overarching issue tracking the work is #63768

[deeprobin]

Thank you 👍