引用参数的 C# 11 转义规则：ref int 与 Span<int>

您确定使用的是 C# 11 吗？将 linqpad 与 .Net 7 一起使用，您的“编译失败”示例对我来说效果很好：

编译良好

更新：如果使用 Rosyln 编译器的每日构建，则无法编译

我的新假设是，规范实际上变得更加严格......ex1 和 ex2 都应该失败，但它们没有考虑 ex2 语法，其中它没有在应该触发的时候触发（出于 Marc G 指出的原因），所以可能值得就此提交错误报告：-）

This very closely related issue had been reported to the Roslyn team before and closed as "by design".

The issue is that the compiler associates an internal scope with a variable of a type such as a . This scope is decided at the moment the variable is declared.ref structspan<>

Later on, when assignments happen, the internal scopes are compared.

Although both the uninitialized local span<> variable as well as the span<> variable wrapped around the ref argument should be returnable from the method, the compiler seems to think otherwise.

I would report this concrete example to the Roslyn team and see what they say about it.

Previous musings:

It is an issue of scope. Look at this more explicit example:

public void M()
{
    Span<int> spanOuter;
    {
        int answer = 42;
        spanOuter = new Span<int>(ref answer); // Compiler error
    }

    Console.WriteLine(spanOuter[0]); // Would access answer 42 which
                                     // is already out of scope
}

The created has a narrower scope than the variable . You cannot assign spans to another span with a broader scope because that could mean that the referenced data they hold is accessed after they don't exist any more. In this example, the variable goes out of scope before is accessed.new Span<int>()spanOuteranswerspanOuter[0]

Let's remove the curly braces:

public void M()
{
    Span<int> spanOuter;
    int answer = 42;
    spanOuter = new Span<int>(ref answer); // Compiler error
    Console.WriteLine(spanOuter[0]); 
}

Now this should in theory work because the variable is still in scope at the . The compiler still doesn't like it. Although there are no curly braces, the variable still has a broader scope than at the expression because its declaration happens on its own on a previous line.answerConole.WriteLinespanOuternew Span<int>()

When checking for breadth of scope, the compiler seems to be very strict and difference in scope just because of the separate variable declaration seems to be enough to not allow the assignment.

Even when we move the variable at the very beginning so that it basically has the same scope as an argument has, it is still not allowed.answer

public void M()
{
    int answer = 42;
    Span<int> spanOuter;
    spanOuter = new Span<int>(ref answer); // Compiler error
    Console.WriteLine(spanOuter[0]); 
}

The compiler seems to treat arguments just like local variables for this check. I agree that the compiler could be a bit more clever, look at the precise scope of the referenced data and allow some more cases, but it just doesn't do that.

Specifically, the compiler seems to have a special treatment when the target span variable is uninitialized as seen by the compiler.

public void M(ref int a)
{
    int answer = 42;

    Span<int> spanNull = null;
    Span<int> spanImplicitEmpty;
    Span<int> spanExplicitEmpty = Span<int>.Empty;
    Span<int> spanInitialized = new Span<int>(ref answer);

    Span<int> spanArgument = new Span<int>(ref a);

    spanNull            = spanArgument; // Compiler Error
    spanExplicitEmpty   = spanArgument; // Compiler Error
    spanImplicitEmpty   = spanArgument; // Compiler Error
    spanInitialized     = spanArgument; // Works
}

使用返回值时也是如此：

public Span<int> M(ref int a)
{
    int answer = 42;

    Span<int> spanNull = null;
    Span<int> spanImplicitEmpty;
    Span<int> spanExplicitEmpty = Span<int>.Empty;
    Span<int> spanInitialized = new Span<int>(ref answer);
    
    Span<int> spanInitializedAndThenNull = new Span<int>(ref answer);
    spanInitializedAndThenNull = null;

    Span<int> spanArgument = new Span<int>(ref a);

    spanNull                    = spanArgument; // Compiler Error
    spanExplicitEmpty           = spanArgument; // Compiler Error
    spanImplicitEmpty           = spanArgument; // Compiler Error
    spanInitialized             = spanArgument; // Works
    spanInitializedAndThenNull  = spanArgument; // Works

    return spanArgument;
}