It's common for teams building IO/data pipelines to invent a type similar to Span\<T>, which is intended to abstract over native and managed memory, so that you write code over them only ones.
So need a way to specify ref-like types, so that the compiler wants to enforce it.
The stack-only-ness helps not having to spend anything on lifetime issues. It lets you pass it to something, and when they return you know they didn't keep any references to it.
Should we make existing types "span-aware"? Arrays? Strings?
We need to figure out what the right trade-off is.
For the rest there's wrapper types that are not limited to the stack, and can go into Span-land on demand.
Ref-like types
==============
Let's call the ref-like types "ref structs".
(Unlike refs these can be fields. ref fields require new runtime semantics, whereas we can otherwise make do with runtime *optimizations*, so we'll skip on ref fields for now)
Ref-like-ness should be declarative; it shouldn't be something you infer. Because something could change somewhere else that changes whether you are or not.
(The structs capturing ref-like locals when you have local functions would be inferred. But that's locally in code).
A problem something like Span may have at the language level is that it doesn't *look* like something that restrictions apply to, unlike `ref int` or `int*`. We could at least have a naming convention.
``` c#
M(await X, GetSpan());
```
Lifting out GetSpan() to a local wouldn't work. So that speaks to there being a notation on usage.
* Nothing?
* Naming conventions?
* syntax? `ref`? `*`?
Is this really only going to be done by 1% of users (which is still many).
Stackalloc
----------
``` c#
Span<byte> s = stackalloc byte[4];
```
Ref return rules
----------------
Need to be adjusted a bit. YOu should only be able to return spans to things that are safe to return.
Downlevel use
-------------
Do we need to poison these type for downlevel import, and how do we do that?
If we want to enable spans representing strings, for instance, we need readonly spans. And their indexer needs to return a readonly ref.
Not so central to this proposal, but generally interesting: Can we make struct methods that don't copy (their `this` would be readonly ref)? In practice you'd probably want to call the whole struct readonly.
Slicing
=======
Essentially an API feature, but would want nice overloadable syntax.
Structs that can't be passed by value
-------------------------------------
TO avoid copying costs, semantic errors etc. Icing.