为什么 Span<T> 扩展方法不使用 'in' 参数修饰符实现？

Question

随着 C#7.2 的发布，in参数修饰符和Span<T>struct出现了。Spans 现在已经充斥着 .NET Core 周围的 API。还发布了 .NET 标准 API ( System.Memory )，可以使用Span<T>、ReadOnlySpan<T>等。

API的一部分System.Memory是这些切片类型的扩展方法，如此处所示。

问题是，为什么不使用in跨度的参数修饰符来实现这些扩展方法？由于Span<T>和ReadOnlySpan<T>是ref readonly struct类型，因此这些方法似乎会导致运行时创建传递给这些方法的跨度的防御性副本。据我所知，这个副本相对便宜，但似乎会看到很小的性能提升。

这些扩展方法的一些 .NET Core 实现位于此处。

为了澄清起见，我期待这样的方法签名：

public static int IndexOf<T>(this in System.Span<T> span, T value) where T : System.IEquatable<T>
public static System.ReadOnlySpan<char> Trim(this in System.ReadOnlySpan<char> span)
public static bool IsWhiteSpace(this in System.ReadOnlySpan<char> span)

Answer 1

因为in既有优点也有缺点；大多数优点都围绕结构复制性能，并避免不必要的大型结构副本（特别强调“大”），但Span<T> 不是大型结构，并且在我见过的几乎所有测试中，使用inonSpan<T>要么减少了性能，或者（不太常见）对性能没有影响- 因此即使在最好的情况下（不会降低性能），也没有真正的理由添加它。