Copied from https://github.com/dotnet/csharplang/blob/ef449a65b4c46e124b604213f11073b23675a93e/proposals/csharp-7.2/span-safety.md And then edited to use the terminilogy from dotnet/csharpstandard#795
The main reason for the additional safety rules when dealing with types like Span<T> and ReadOnlySpan<T> is that such types must be confined to the execution stack.
There are two reasons why Span and similar types must be a stack-only types.
| # Generate a pattern-match that is likely to blow up the state machine. | |
| # Intended for use in diagnosing ways to reduce the size of the state machine. | |
| # | |
| # The Julia macro @match in Rematch2 attempts to avoid repeating tests in the code | |
| # generated to determine which is the first matching case. It does this by encoding | |
| # in the state of the generated decision automaton (i.e. the program counter during | |
| # execution) which tests have succeeded and which have failed. As a side-effect, | |
| # this construction permits us to diagnose pattern-matching cases that are | |
| # impossible (because previous cases would match), and matches that are incomplete | |
| # (because some input values would not match any case). |
Giving the compiler flexibility in reordering the operations executed during pattern-matching can permit flexibility that can be used to improve the efficiency of pattern-matching. The (unenforced) requirement would be that properties accessed in a pattern, and the Deconstruct methods, are required to be "pure" (side-effect free, idempotent, etc). That doesn't mean that we would add purity as a language concept, only that we would allow the compiler flexibility in reordering operations.
Resolution 2018-04-04 LDM: confirmed: the compiler is permitted to reorder calls to Deconstruct, property accesses, and invocations of methods in ITuple, and may assume that returned values are the same from multiple calls. The compiler should not invoke functions that cannot affect the result, and we will be very careful before making any changes to the compiler-generated order of evaluation in the future.
If we have a range operator 1..10, would we