为什么零长度的stackalloc会让C#编译器乐于允许条件stackalloc呢？

Question

下面的“搞定”对我来说很迷惑；这里的场景是根据大小有条件地决定是否使用堆栈还是租用缓冲区--这是一个相当小的小范围，但有时--必要的优化，然而：对于“明显的”实现（第3条，推迟确定的赋值，直到我们真正想要赋值），编译器向CS8353抱怨：

在此上下文中不能使用“span ”类型的stackalloc表达式的结果，因为它可能在包含方法的外部公开

简短的复制品（完整的复制品如下）是：

// take your pick of:
// Span<int> s = stackalloc[0]; // works
// Span<int> s = default; // fails
// Span<int> s; // fails

if (condition)
{   // CS8353 happens here
    s = stackalloc int[size];
}
else
{
    s = // some other expression
}
// use s here

这里我唯一能想到的是，编译器实际上是在标记stackalloc正在转义stackalloc发生的上下文，并且在挥舞一个标记说“我无法证明这在方法的后面是否会是安全的”，但是通过在开始时使用stackalloc[0]，我们将“危险”上下文范围推高，现在编译器很高兴它从未转义“危险”范围（即它从未离开方法，因为我们在顶部范围声明）。这种理解是正确的吗，就可以证明的内容而言，它只是一个编译器的限制？

（对我来说）真正有趣的是，=stackalloc[0]基本上是一个no-op，这意味着至少在编译的形式下，工作号1=stackalloc[0]与失败号2=default是相同的。

完全再现（也可在SharpLab上查看IL）。

using System;
using System.Buffers;

public static class C
{
    public static void StackAllocFun(int count)
    {
        // #1 this is legal, just initializes s as a default span
        Span<int> s = stackalloc int[0];
        
        // #2 this is illegal: error CS8353: A result of a stackalloc expression
        // of type 'Span<int>' cannot be used in this context because it may
        // be exposed outside of the containing method
        // Span<int> s = default;
        
        // #3 as is this (also illegal, identical error)
        // Span<int> s;
        
        int[] oversized = null;
        try
        {
            if (count < 32)
            {   // CS8353 happens at this stackalloc
                s = stackalloc int[count];
            }
            else
            {
                oversized = ArrayPool<int>.Shared.Rent(count);
                s = new Span<int>(oversized, 0, count);
            }
            Populate(s);
            DoSomethingWith(s);
        }
        finally
        {
            if (oversized is not null)
            {
                ArrayPool<int>.Shared.Return(oversized);
            }
        }
    }

    private static void Populate(Span<int> s)
        => throw new NotImplementedException(); // whatever
    private static void DoSomethingWith(ReadOnlySpan<int> s)
        => throw new NotImplementedException(); // whatever
    
    // note: ShowNoOpX and ShowNoOpY compile identically just:
    // ldloca.s 0, initobj Span<int>, ldloc.0
    static void ShowNoOpX()
    {
        Span<int> s = stackalloc int[0];
        DoSomethingWith(s);
    }
    static void ShowNoOpY()
    {
        Span<int> s = default;
        DoSomethingWith(s);
    }
}

Answer 1

span /ref 特性本质上是一系列规则，给定值可以通过值或引用转义到哪个作用域。虽然这是根据方法范围编写的，但简化为两个语句中的一个很有帮助：

1. 无法从方法返回值
2. 值可以从方法返回

span安全文档详细介绍了如何为各种语句和表达式计算作用域。这里的相关部分是如何处理本地数据的。

主要带走的是，一个本地能否返回是在本地申报时间计算的。在声明本地时，编译器检查初始值设定项，并决定是否可以从方法返回本地值。如果有一个初始化器，那么如果能够返回初始化表达式，则本地将能够返回。

如何处理声明了局部值但没有初始值设定项的情况？编译器要做一个决定：它能返回还是不能返回？在设计特性时，我们决定默认值为“It can be return”，因为这是对现有模式造成最小摩擦的决定。

这确实给我们留下了一个问题，即开发人员如何声明一个返回时不安全但又缺少初始化器的本地。最终我们确定了=stackalloc[0]的模式。这是一个可以安全优化的表达式，也是一个很强的指标，基本上是一个要求，表明本地返回时不安全。

知道这解释了你所看到的行为：

• span s=stackalloc[0] :返回该值不安全，因此后面的stackalloc成功
• span s=default :返回该值是安全的，因为返回default是安全的。这意味着后面的stackalloc会失败，因为您将不安全返回的值分配给标记为安全返回的本地
• span s； :返回该值是安全的，因为这是未初始化的局部变量的默认值。这意味着后面的stackalloc会失败，因为您将不安全返回的值分配给标记为安全返回的本地

=stackalloc[0]方法的真正缺点是它只适用于span 。它不是ref struct的通用解决方案。但在实践中，这对其他类型的人来说并不是一个大问题。有一些猜测，我们可以如何使它更普遍，但没有足够的证据证明这样做的理由在这一点上。