Interesting idea, but most interesting to me is the stack-only restriction. I'm curious how they're going to enforce that, and whether that property will be limited to Span or can be used with other types.
The fast representation makes the type automatically stack-only, i.e. the constraint
will be enforced by CLR type loader. This restriction should also be enforced by
managed language compilers and/or analyzers for better developer experience. For
the slow span, language compiler checks and/or analyzers is the only option (as
the runtimes won't enforce the stack-only restriction).You can already see this in the "ref parameters" feature in C# today: they can be parameters to methods but cannot be stored in fields. This implies that they can only exist on the stack.
Similarly, when we add support for ref-locals and ref-returns in C# 7 that will still disallow ref fields, so ref variables will still only be allowed on the stack.
Problem with that is that a small substring of a larger string prevents the data buffer of the larger string to be garbage collected.
That happened a lot when parsing files. Let's say you read a 1 GB, 10M row cvs file with a small string ID and 10 integers on each line. The strings should take maybe 100MB, but they will take 1GB. Oops.
The behaviour of the substring function changed to copy string data in JDK7 (after quite a bit of deliberation. There was a nice writeup of the results somewhere, but I can't find it)