[Version 10.0] Feature support for improved definite assignment - #1545
[Version 10.0] Feature support for improved definite assignment#1545RexJaeschke wants to merge 5 commits into
Conversation
| An expression *E* is said to ***directly contain*** a subexpression *E₁* if it is not subject to a user-defined conversion [§10.5](conversions.md#105-user-defined-conversions) whose parameter is not of a non-nullable value type, and one of the following conditions holds: | ||
|
|
||
| - *E* is *E₁*. | ||
| - If *E* is a parenthesized expression `(E₂)`, and *E₂* directly contains *E₁*. | ||
| - If *E* is a null-forgiving operator expression `E₂!`, and *E₂* directly contains *E₁*. | ||
| - If *E* is a cast expression `(T)E₂`, and the cast does not subject *E₂* to a non-lifted user-defined conversion whose parameter is not of a non-nullable value type, and *E₂* directly contains *E₁*. | ||
|
|
There was a problem hiding this comment.
The MS proposal had this text in the new section, 9.4.4.3x ?.expressions, but as this text is general, and not specific to that expression form, I thought it did not belong there. Short of creating a new section just for this text, I put it in 12.1. Is that OK?
| - The definite-assignment state of *v* before *expr_second* is the same as the definite-assignment state of *v* after *expr_first*. | ||
| - The definite-assignment statement of *v* after *expr* is determined by: | ||
| - If *expr_first* is a constant expression ([§12.26](expressions.md#1226-constant-expressions)) with value `null`, then the state of *v* after *expr* is the same as the state of *v* after *expr_second*. | ||
| - If *expr_first* directly contains ([§12.1](expressions.md#121-general)) a null-conditional expression *E*, and *v* is definitely assigned after the non-conditional counterpart *E₀* (§qdot-expressions), then the definite assignment state of *v* after *expr* is the same as the definite assignment state of *v* after *expr_second*. |
There was a problem hiding this comment.
The instructions in the MS spec for including the new bullet are unclear. They appear to suggest adding the new bullet at the end of the level-2 bullet list. However, that would make it come after the currently final “Otherwise” bullet, which doesn’t seem right. So, I inserted the new bullet before that bullet. Please check if that makes sense.
| - If the state of *v* after *expr_true* is “definitely assigned when true,” and the state of *v* after *expr_false* is “definitely assigned when true,” then the state of *v* after *expr* is “definitely assigned when true.” | ||
| - If the state of *v* after *expr_true* is “definitely assigned when false,” and the state of *v* after *expr_false* is “definitely assigned when false,” then the state of *v* after *expr* is “definitely assigned when false.” |
There was a problem hiding this comment.
The instructions in the MS spec for including the new bullets are unclear. They appear to suggest adding the new bullets at the end of the level-2 bullet list. However, that would make them come after the currently final “Otherwise” bullet, which doesn’t seem right. But that’s where I put them. Please check if that makes sense.
2ff657f to
6da0f8f
Compare
| > | ||
| > *end note* | ||
|
|
||
| #### §isop-ispattern-expressions is operator and is pattern expressions |
There was a problem hiding this comment.
I'm curious how this differs from 9.4.4.34 (is pattern expression). Should these two clauses be merged? If not, we need text explaining why they are different.
6da0f8f to
3fa8a5c
Compare
3fa8a5c to
672c696
Compare
672c696 to
50f43d5
Compare
|
An earlier version of this feature is already present on |
`=> null` should be `=> default` in `S2` example because `S2` is a struct. Remove extra `)` from example note Change *null* to `null` add cross references hyphenate "definite-assignment" state
50f43d5 to
36c3362
Compare
This is Rex's adaptation of the corresponding MS proposal.