The fact that it can point to unmanaged memory is a benefit for me. Just last week I’ve been porting some performance critical code to C++\CLI and this will allow me to use a span of of object instead of having to pin arrays. One other application is that it is now possible to implement a memory pool using a contiguous piece of memory and only returning slices of it, previously you would have to have multiple instances of a fixed size array in the pool.

I don't sling C#, but the best I can summarize the doc's claims, it looks like a standard for referencing memory in previously unsupported ways, e.g. for representing a substring of a longer string, or a section of a buffer pool. If you do performance-critical code, you can avoid copying some data or alternatively defining your own ad-hoc slice types. If you don't, optimized libraries that you call will get another tool to minimize data-copying.

It will have some limitations, like that it can only be used on the stack. One reason is that the efficient representation on new CLRs will use pointers into the middle of objects and they argue that supporting those on the heap will slow down the GC too much. (Go's approach to non-copying slices/strings was just to support pointers into the middle of allocations, and I guess accept the costs at GC time.) Other reasons relate to concurrency, etc.

I can't do much better than that not knowing more about C# and the CLR than I do!

Lots of high performance goodness. Implement function taking Span as a parameter and it can be called with an array, stackalloc'd memory, native memory with a single implementation and in a type safe way.

However, an item I think is often overlooked is the safety:

ArraySegment or the triple: "array, offset, length" when used; only provides a suggestion to the called function - it still has full access to the array and can happily read and write out of offset->length portion of the array. Span only allows access to the window, so the called function can't operate out of its permitted bounds.

Further to this ReadOnlySpan finally gives read-only array elements; so rather than having to a defensive copy and passing out a newly allocated array; you can pass out (or in) a ReadOnlySpan

This solves the problem of not allowing low level optimisations in interacting with memory that are C/C++ developers bread and butter.

Most C# developers won't use it directly, but rather benefit from wide ranging performance increases in the libraries they use.

C# is being used more and more for high performance applications. This feature will allow developers working in gamedev/finance/server networking to get even closer to the metal without sacrificing safety.

If you wanted to replace a bunch of characters in a string. I.e. all 'a' to 'b' you can operate on the span, and not have to re-allocate a new string after each replacement

Not having to go down into C++ or C++/CLI to express performance algorithms that now can be fully written in pure C#.