[Version 9.0] Feature support for record classes#1458
Conversation
BillWagner
changed the title
|
|
||
| An awaiter’s implementation of the interface methods `INotifyCompletion.OnCompleted` and `ICriticalNotifyCompletion.UnsafeOnCompleted` should cause the delegate `r` to be invoked at most once. Otherwise, the behavior of the enclosing async function is undefined. | ||
|
|
||
| ## §with-expressions With expressions |
There was a problem hiding this comment.
We need to add "with" as a new row to the table in the (earlier) section "Operator precedence and associativity." And as we have historically organized the sections in this clause in descending precedence order, we might need to move this new section up or down, accordingly.
|
|
||
| The method performs the following tasks: | ||
|
|
||
| 1. Calls the method `System.Runtime.CompilerServices.RuntimeHelpers.EnsureSufficientExecutionStack()` if that method is present and the record class has printable members. |
There was a problem hiding this comment.
Do we really want to expose this type in the spec?
RexJaeschke
changed the title
|
Based on Issue #1683, I have updated the grammar for class_declaration. Re my choice of grammar rule name prefixes, “non-record” and “record,” for a reader starting at 15.1, which says nothing about records, you might think we should not use the word “record” here. I’m OK with that. As a strawman, how about we call the two class flavors “plain class” and “record class?” (I think “class” and “record class” is not a clear enough distinction, as “class” might mean any class or just a non-record class.) I currently use the two-favor distinction in new definitions, as follows:
This might then become:
I’m thinking that all existing uses of “class” will apply to both flavors, so no distinction will be needed for them. For now, I’ll use “non-record” and “record.” |
Add support for record classes Add files via upload Add support for record classes Add support for record classes fix markup fix markdown formatting fix markdown formatting fix link another missed link
Tweaks I made when comparing this PR with what I researched 2+ years ago.
|
An earlier version of this feature is already present on |
|
After researching and writing-up "Primary constructors" as a general feature in v12 for classes and structs outside of record variants, I have made a lot of tweaks to this spec (and to the V10 record struct spec) to ease the transition to that v12 spec. |
3 participants
All commits from #983 have been squashed and added to this PR.
This PR / feature makes numerous changes to the grammar. We still need corresponding updates to the test and validation suite.
The following notes are carried over for additional work needed:
A. I put the new subclause "With expression" prior to "Arithmetic operators", which once the V8 features "Indices and Ranges" and "Pattern matching" have been merged, should immediately follow "Range operator" and "Switch expression." Make sure these are all in the correct place. 12.4.2 Operator precedence and associativity will also need to be revised accordingly.
B. New subclause §rec-class-prtmem Printing members mentions a method
System.Runtime.CompilerServices.RuntimeHelpers.EnsureSufficientExecutionStack(). It's quite possible that this is an implementation-specific detail, in which case, we'll need to find words to make it abstract, and possibly update the Portability annex accordingly.