v7.x Q.s re ref struct

[RexJaeschke]

This issue is intended to help complete the (Draft) PR #333.

A. Terminology, "execution stack"

As drafted, the PR states

The ref modifier indicates that the struct_declaration declares a type whose instances are allocated on the execution stack.

The term "execution stack" occurs in the spec in the following places:

exceptions.md: System.StackOverflowException -- Thrown when the execution stack is exhausted by having too many pending calls; typically indicative of very deep or unbounded recursion.

expressions.md: - E is evaluated. If this evaluation causes an exception, then no further steps are executed. For an instance constructor, this evaluation consists of allocating storage (typically from an execution stack) for the new object. ...

The term "call stack" occurs three times in unsafe.md.

The term "stack" on its own appears in unsafe.md ("... to allocate a buffer of 16 characters on the stack".)

Q1. Should we consolidate the various kinds of uses of "stack"?

Q2. Is it a spec requirement that a ref struct instance be on the stack, or could it be in some other "fixed" place?

Bill thought perhaps we might consider borrowing words from "23.4 Fixed and moveable variables." That section currently contains the following:

The address-of operator (§23.6.5) and the fixed statement (§23.7) divide variables into two categories: Fixed variables and moveable variables.
Fixed variables reside in storage locations that are unaffected by operation of the garbage collector. (Examples of fixed variables include local variables, value parameters, and variables created by dereferencing pointers.) On the other hand, moveable variables reside in storage locations that are subject to relocation or disposal by the garbage collector. (Examples of moveable variables include fields in objects and elements of arrays.)

Perhaps we could massage this and move it out of the unsafe.md chapter, as it applies to non-unsafe things as well, and then use "fixed" rather than "stack-based."

B. What to include in the spec w.r.t "safe-to-escape" scopes

The primary starter document for the ref struct specification is https://github.com/dotnet/csharplang/blob/standard-proposals/proposals/csharp-7.2/span-safety.md (hereinafter called the span-safety spec). This document is broken into the following main sections: Introduction and Explanations, Draft language specification, and Language Constraints, the last two of which contain standards-like wording.

This paper has a lot of background/rationale/tutorial material. It talks about expressions and lvalues “escaping to a scope” and draws some parallels to the ref locals feature. My reaction was that this is interesting background with some implementation details, but how much of it belongs in a standard? As a result, I posed the following question:

Presumably, the whole idea of “escaping” and related scopes needs to be in the spec. Do you agree?

Jared Parsons’ (MS) response> This impacts type / memory safety hence I would lean towards it being included in the spec.

Should we have a unification approach to “all-things-ref”? That is, if the answer to Q1 above is to have a general intro and specifics spread around the spec, should they factor in the use of ref with arguments/parameters (the only use of ref prior to V7)? If so, should the existing ref arg/param text be adjusted (if necessary) to use any new terminology?

Separately, the spec currently uses “reference” in a number of unrelated ways: variable reference, reference type, reference argument/parameter, and then there is ref. It seems confusing to use “reference” in any discussion of ref; perhaps “alias” would be better.

Jared Parsons’ response> I agree we need to get crisp now because ref values are a lot more prominent in the language than they used to be. Consistency around when we are referring to a ref value vs. an alias would likely make the spec a lot more readable.

Q3. The bottom line is "How much do we need to include in the spec w.r.t Scopes and Escaping?"

C. Lvalues and Rvalues

The span-safety-spec mentioned above makes considerable use of the (C-language) terms lvalue and rvalue. As C# does not traffic in those terms, we'd need to use something like variable reference and value, respectively.

---

Associated WorkItem - 52133

[BillWagner]

Bill thought perhaps we might consider borrowing words from "23.4 Fixed and moveable variables."

My thinking is this:

The important fact for "ref safe to escape" is not that the storage is "a stack". Rather, the important fact is that "the compiler can assume the memory used for a variable isn't going to move due to a GC cycle." That's a lot of what is demanded for "fixed" memory, so may be we can borrow some of that normative language.

There are also important differences: Instead of forcing the memory to be fixed, a ref struct can only be used where those guarantees are followed.

[jskeet]

This should be fixed by #795.