Add III.1.7 "Managed pointers exposing parameters outside of the method scope" to Ecma-335-Augments.md

docs/design/specs/Ecma-335-Augments.md

@@ -1030,6 +1030,16 @@ Changes to signatures:
   - Managed pointers which point at the address just past the end of an object, or the address where an element just past the end of an array would be stored, are permitted but not dereferenceable.
   - Null managed pointers are permitted to be dereferenced resulting in a `NullReferenceException`.
 
+### III.1.7.7
+Add a new paragraph "III.1.7.7 Managed pointers exposing parameters outside of the method scope" under section "III.1.7 Restrictions on CIL code sequences"
+Managed pointers obtained from method parameters, and byref-like values that contain them, can be made observable outside of a function only through escape paths present in the function signature:
+- By explicit return of a byref or byref-like type
+- By writing to storage exposed by a byref parameter, including byref-like types containing multiple levels of byref fields
+
+The same rule applies to unsafe code. Copying such a managed pointer or byref-like value through unmanaged or other raw storage is permitted, but it is undefined behavior to copy it into storage that makes it observable outside of the function through an escape path not present in the signature. Temporary copies in storage that is not observable outside of the function are permitted.
+
+For example: `void M(Span<T> p)` cannot expose `p` outside of `M`, while `void M(Span<T> p, ref Span<T> q)` can copy `p` into `q`.
+
 ## <a name="byreflike-generics"></a> ByRefLike types in generics
 
 ByRefLike types, defined in C# with the `ref struct` syntax, represent types that cannot escape to the managed heap and must remain on the stack. It is possible for these types to be used as generic parameters, but in order to improve utility certain affordances are required.
@@ -1194,4 +1204,4 @@ In section II.23.1.15, the following row is added to the table:
 
 ## Implict argument coercion rules
 
-Implicit argument coercion as defined in section III.1.6 does not match with existing practice in CLR runtimes. Notably, implicit argument coercion of an `int32` on the IL evaluation stack to a `native unsigned int` is a sign extending operation, not a zero-extending operation.
+Implicit argument coercion as defined in section III.1.6 does not match with existing practice in CLR runtimes. Notably, implicit argument coercion of an `int32` on the IL evaluation stack to a `native unsigned int` is a sign extending operation, not a zero-extending operation.