Clarify Span<T> rules #1593
Clarify Span<T> rules #1593
Conversation
While discussing `Span<T>` safety rules with the F# team I realized we hadn't fully documented our dependency on the shape of the `Span<T>` API. Added that plus some of the future considerations we discussed for `Span<T>`. dotnet/fsharp#4888
|
CC @OmarTawfik |
| This feature gets more compelling if we lift the restrictions on (fixed sized buffers)[https://github.com/dotnet/csharplang/blob/master/proposals/fixed-sized-buffers.md] as it would | ||
| allow for `Span<T>` instances of even greater length. | ||
|
|
||
| If there is ever a need to go down this path then the language could accommodate this by ensuring such `Span<T>` instances |
There was a problem hiding this comment.
Not sure this would work. By the time we would want to make that change, there might already be a user-declared type
internal ref struct MySpan<T>
{
public MySpan(ref T data) ...;
}This API is perfectly safe today because it doesn't (has no safe way to) capture the data.
MySpan<int> M(int x)
{
return new MySpan<int>(ref x);
}Although this is safe today, but would become illegal under the rule changes we would need to permit a Span that can capture a reference. And so would be a breaking change.
There was a problem hiding this comment.
That constructor though couldn't be implemented in a way that captured ref T data. If it attempted to do so via Span<T> then it would be an error as the value wouldn't be escapable beyond the constructor body and hence couldn't be assigned to a field.
There was a problem hiding this comment.
Yes, that would work. Because:
- we do not have such constructors on Span/ReadOnlySpan right now.
- with suggested restrictions the resulting instances will never escape the scope that contains the constructor invocation, so they will not introduce any new escaping scenarios for the outer scopes.
There was a problem hiding this comment.
I would also add that in a case when the ref argument is "definitely referring to a heap object" - like a ref to an array element, for example, the resulting instance could be allowed to escape. It feels like it might be another common case.
proposals/csharp-7.2/span-safety.md
Outdated
| # Future Considerations | ||
|
|
||
| ## Length one Span<T> over ref values | ||
| Though legal today there are cases where creating a length one `Span<T>` instance over a value would be beneficial: |
|
Updated based on feedback. |
While discussing
Span<T>safety rules with the F# team I realized wehadn't fully documented our dependency on the shape of the
Span<T>API. Added that plus some of the future considerations we discussed for
Span<T>.dotnet/fsharp#4888