Skip to content

Commit 1718a86

Browse files
BillWagnerjskeetNigel-EcmagafterNeal Gafter
authored
Merge all features related to C# 7 ref features (#795)
* Add rules for `ref` safety (#742) * first pass at safety rules This mostly incorporates the feature spec language. * Add rule for `out` parameters Out parameters have a ref safe to escape scope of the current method, not the calling method. * Add readonly rule. * fix headers no code fences in headers * Apply suggestions from code review Co-authored-by: Jon Skeet <[email protected]> * updates from reviews Updates from code review * style fix * respond to feedback Ref like fields do have storage, but that storage may refer to a variable that is a struct parameter or varialbe. * respond to feedback Respond to existing feedback. * Introduce definitions Introduce better definitions for the "lifetime" of reference variables. I avoided the term "lifetime' because of its runtime connotation. Instead, I used the "scope" where a "variable declaration" is valid. From there, next define the safe scopes and the ref safe scopes for different variable classifications. Finally, I shortened the terms *safe-to-escape-scope* and *ref-safe-to-escape-scope* to "*safe-scope* and *ref-safe-scope*. The text doesn't make it clear why the "escape" term is used, and it doesn't seem to add clarity. * add examples * respond to feedback. * Apply suggestions from code review Co-authored-by: Jon Skeet <[email protected]> * address review comments This addresses most of the comments in the most recent reviews. The next commit will make an attempt to use a single term for *ref_safe_scope*. * Remove *safe_scope* rules Once I push these, I'll add notes about which rules must be added to #601 * Update standard/variables.md Co-authored-by: Nigel-Ecma <[email protected]> * Update standard/variables.md * Respond to review comments. * Feedback from April meeting This include comments, and fixing the formatting after consulting with Rex. * remove ref struct descriptions These belong in the PR for ref structs, and in the section on ref structs. * Apply suggestions from code review Co-authored-by: Jon Skeet <[email protected]> * respond to feedback. * Apply suggestions from code review Co-authored-by: Nigel-Ecma <[email protected]> * remove missing xref This needs to be added to #213 once this PR is merged. * Updates from 5/17 meeting. Updates from the 5/17 meeting. * fix build warning --------- Co-authored-by: Jon Skeet <[email protected]> Co-authored-by: Nigel-Ecma <[email protected]> * C# 7.x: ref struct (#601) * Split out `ref struct` from #33. * Add ref safety rules as they apply to ref structs Declare that `ref structs` have a *ref_safe_scope* that matches their initializing expressions. Restrict copying of a `ref struct` (by value) to its *ref_safe_scope*. Then, define what the *ref_safe_scope* is depending on the initializing expression. * forgot to finish one sentence. * Add note on iterators and async methods The previous normative language was * respond to review feedback. * Respond to meeting feedback, part 1 Respond to all meeting feedback *except* updating the rules on *safe_to_escape*. That's coming in the next commit. * incorporate safe rules. Pull all safety rules related to safe-scope from PR on ref variables into the section on ref structs. * respond to feedback. * Apply suggestions from code review Co-authored-by: Jon Skeet <[email protected]> * respond to feedback. * Apply suggestions from code review Co-authored-by: Nigel-Ecma <[email protected]> * respond to feedback. * Update per 5/17 committee meeting. * update definition * found one more comment to address --------- Co-authored-by: Neal Gafter <[email protected]> Co-authored-by: Bill Wagner <[email protected]> Co-authored-by: Jon Skeet <[email protected]> Co-authored-by: Nigel-Ecma <[email protected]> * C# 7.x: ref locals and returns (#213) * Update expressions.md * Update statements.md * Update classes.md * Update delegates.md * Relocate ('ref' 'readonly'?)? to local_variable_declaration I had this grammar extension in the wrong place * Add support for ref readonly iteration variables to foreach * Minor tweak to v7 spec for ? ref : ref * build fixes * fix merge error * one more build issue * light editing * fix section references * fix link errors * edit to address feedback, link to ref safety rules. * fix markdown lint error * Apply suggestions from code review Co-authored-by: Jon Skeet <[email protected]> * respond to feedback * respond to feedback. * Apply suggestions from code review Co-authored-by: Jon Skeet <[email protected]> * Update per April meeting feedback. * formatting while checking grammar * updates from 5/17 committee meeting. * remove blank line. * fix warnings --------- Co-authored-by: Bill Wagner <[email protected]> Co-authored-by: Jon Skeet <[email protected]> * C# 7.x: in parameter mode (#219) * Update basic-concepts.md * Update variables.md * Update conversions.md * Update structs.md * Update interfaces.md * Update delegates.md * Update unsafe-code.md * Update documentation-comments.md * Update classes.md * Update expressions.md * include support for local functions * fix merge tag * fix build warnings * build fixes * build fixes, round 1 * build fixes, part 2 * one last link fix * light edits based on earlier feedback. * respond to remaining feedbac,. * one final edit.... * clarification on `ref` extension methods * Apply suggestions from code review Co-authored-by: Jon Skeet <[email protected]> * respond to feedback * Update standard/expressions.md Co-authored-by: Jon Skeet <[email protected]> * Update standard/expressions.md * Apply suggestions from code review Co-authored-by: Jon Skeet <[email protected]> * Update per April meeting notes. * respond to feedback. * Exclude dynamic implicit conversions A dynamic expression can't be passed as an `in` parameter if an implicit conversion is required. * Clarify restrictions on `in` parameters Dynamically bound expressions can't use the `in` modifier. * Apply suggestions from code review Co-authored-by: Neal Gafter <[email protected]> * Updates from 5/17 committee meeting. * fix warning --------- Co-authored-by: Bill Wagner <[email protected]> Co-authored-by: Jon Skeet <[email protected]> Co-authored-by: Neal Gafter <[email protected]> * C# 7.x: Add initializer list to `stackalloc` (#238) * Update unsafe-code.md * Update unsafe-code.md * Move most of stackalloc spec from unsafe to here * Impact of moving most of stackalloc spec from unsafe to expressions * Moved most of stackalloc spec to expressions * Fix links to new stackalloc spec location * Add Span & ReadOnlySpan types * fix build issues * address feedback * Stack initializers are only allowed as local variable initializers This clarifies and simplifies some of the language for this PR. * fix markdown lint issue * respond to feedback. * fix build issues * one more round of build issues * respond to feedback. * decisions from 5/17 meeting. * add safe context rules. --------- Co-authored-by: Bill Wagner <[email protected]> * fix build warnings * Apply suggestions from code review Co-authored-by: Nigel-Ecma <[email protected]> * fix references * add closing backticks One grammar rule was missing the closing backticks. This caused several build errors. * respond to feedback through clause 15 (classes) This commit responds to feedback with the 👍 emoji through clause 15. * respond to feedback. * Apply suggestions from code review Co-authored-by: Nigel-Ecma <[email protected]> * rearrange conditional specification * Update standard/expressions.md Co-authored-by: Nigel-Ecma <[email protected]> * Update standard/variables.md Co-authored-by: Nigel-Ecma <[email protected]> * edits based on feedback. * Update standard/expressions.md Co-authored-by: Jon Skeet <[email protected]> * respond to feedback comments * Apply suggestions from code review Co-authored-by: Nigel-Ecma <[email protected]> * more feedback * Update standard/classes.md Co-authored-by: Nigel-Ecma <[email protected]> * Update standard/classes.md Co-authored-by: Nigel-Ecma <[email protected]> * Update standard/expressions.md * Update standard/expressions.md * Update standard/expressions.md Co-authored-by: Bill Wagner <[email protected]> * Update standard/variables.md * edits during the meeting. * Update standard/expressions.md Co-authored-by: KalleOlaviNiemitalo <[email protected]> * edits, part 1 * respond to meeting discussion and feedback Address all remaining conversations for this PR. Addresses feedback from 06/05/2023 ECMA committee meeting. --------- Co-authored-by: Jon Skeet <[email protected]> Co-authored-by: Nigel-Ecma <[email protected]> Co-authored-by: Neal Gafter <[email protected]> Co-authored-by: Neal Gafter <[email protected]> Co-authored-by: Jon Skeet <[email protected]> Co-authored-by: Rex Jaeschke <[email protected]> Co-authored-by: KalleOlaviNiemitalo <[email protected]>
1 parent d90f486 commit 1718a86

14 files changed

+791
-154
lines changed

standard/basic-concepts.md

Lines changed: 5 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -522,9 +522,8 @@ The following accessibility constraints exist:
522522
523523
Methods, instance constructors, indexers, and operators are characterized by their ***signatures***:
524524
525-
- The signature of a method consists of the name of the method, the number of type parameters, and the type and parameter-passing mode (value, reference, or output) of each of its formal parameters, considered in the order left to right. For these purposes, any type parameter of the method that occurs in the type of a formal parameter is identified not by its name, but by its ordinal position in the type parameter list of the method. The signature of a method specifically does not include the return type, parameter names, type parameter names, type parameter constraints, the `params` or `this` parameter modifiers, nor whether parameters are required or optional.
526-
527-
- The signature of an instance constructor consists of the type and parameter-passing mode (value, reference, or output) of each of its formal parameters, considered in the order left to right. The signature of an instance constructor specifically does not include the `params` modifier that may be specified for the right-most parameter.
525+
- The signature of a method consists of the name of the method, the number of type parameters, and the type and parameter-passing mode of each of its formal parameters, considered in the order left to right. For these purposes, any type parameter of the method that occurs in the type of a formal parameter is identified not by its name, but by its ordinal position in the type parameter list of the method. The signature of a method specifically does not include the return type, parameter names, type parameter names, type parameter constraints, the `params` or `this` parameter modifiers, nor whether parameters are required or optional.
526+
- The signature of an instance constructor consists of the type and parameter-passing mode of each of its formal parameters, considered in the order left to right. The signature of an instance constructor specifically does not include the `params` modifier that may be specified for the right-most parameter.
528527
- The signature of an indexer consists of the type of each of its formal parameters, considered in the order left to right. The signature of an indexer specifically does not include the element type, nor does it include the `params` modifier that may be specified for the right-most parameter.
529528
- The signature of an operator consists of the name of the operator and the type of each of its formal parameters, considered in the order left to right. The signature of an operator specifically does not include the result type.
530529
- The signature of a conversion operator consists of the source type and the target type. The implicit or explicit classification of a conversion operator is not part of the signature.
@@ -537,9 +536,9 @@ Signatures are the enabling mechanism for ***overloading*** of members in classe
537536
- Overloading of indexers permits a class, struct, or interface to declare multiple indexers, provided their signatures are unique within that class, struct, or interface.
538537
- Overloading of operators permits a class or struct to declare multiple operators with the same name, provided their signatures are unique within that class or struct.
539538
540-
Although `out` and `ref` parameter modifiers are considered part of a signature, members declared in a single type cannot differ in signature solely by `ref` and `out`. A compile-time error occurs if two members are declared in the same type with signatures that would be the same if all parameters in both methods with `out` modifiers were changed to `ref` modifiers. For other purposes of signature matching (e.g., hiding or overriding), `ref` and `out` are considered part of the signature and do not match each other.
539+
Although `in`, `out`, and `ref` parameter modifiers are considered part of a signature, members declared in a single type cannot differ in signature solely by `in`, `out`, and `ref`. A compile-time error occurs if two members are declared in the same type with signatures that would be the same if all parameters in both methods with `out` or `in` modifiers were changed to `ref` modifiers. For other purposes of signature matching (e.g., hiding or overriding), `in`, `out`, and `ref` are considered part of the signature and do not match each other.
541540
542-
> *Note*: This restriction is to allow Cprograms to be easily translated to run on the Common Language Infrastructure (CLI), which does not provide a way to define methods that differ solely in `ref` and `out`. *end note*
541+
> *Note*: This restriction is to allow Cprograms to be easily translated to run on the Common Language Infrastructure (CLI), which does not provide a way to define methods that differ solely in `in`, `out`, and `ref`. *end note*
543542
544543
The types `object` and `dynamic` are not distinguished when comparing signatures. Therefore members declared in a single type whose signatures differ only by replacing `object` with `dynamic` are not allowed.
545544
@@ -567,9 +566,7 @@ The types `object` and `dynamic` are not distinguished when comparing signatures
567566
> }
568567
> ```
569568
>
570-
> Note that any `ref` and `out` parameter modifiers ([§15.6.2](classes.md#1562-method-parameters)) are part of a signature. Thus, `F(int)`, `F(ref int)`, and `F(out int)` are all unique signatures. However, `F(ref int)` and `F(out int)` cannot be declared within the same interface because their signatures differ solely by `ref` and `out`. Also, note that the return type and the `params` modifier are not part of a signature, so it is not possible to overload solely based on return type or on the inclusion or exclusion of the `params` modifier. As such, the declarations of the methods `F(int)` and `F(params string[])` identified above, result in a compile-time error.
571-
>
572-
> *end example*
569+
> Note that any `in`, `out`, and `ref` parameter modifiers ([§15.6.2](classes.md#1562-method-parameters)) are part of a signature. Thus, `F(int)`, `F(in int)`, `F(out int)` , and `F(ref int)` are all unique signatures. However, `F(in int)`, `F(out int)` , and `F(ref int)` cannot be declared within the same interface because their signatures differ solely by `in`, `out`, and `ref`. Also, note that the return type and the `params` modifier are not part of a signature, so it is not possible to overload solely based on return type or on the inclusion or exclusion of the `params` modifier. As such, the declarations of the methods `F(int)` and `F(params string[])` identified above, result in a compile-time error. *end example*
573570
574571
## 7.7 Scopes
575572

0 commit comments

Comments
 (0)