Skip to content

[Version 10.0] Feature support for improved definite assignment - #1545

Draft
RexJaeschke wants to merge 5 commits into
draft-v10from
v10-improved-definite-assignment
Draft

[Version 10.0] Feature support for improved definite assignment#1545
RexJaeschke wants to merge 5 commits into
draft-v10from
v10-improved-definite-assignment

Conversation

@RexJaeschke

Copy link
Copy Markdown
Contributor

This is Rex's adaptation of the corresponding MS proposal.

@RexJaeschke RexJaeschke added this to the C# 10 milestone Jan 23, 2026
@RexJaeschke RexJaeschke added type: feature This issue describes a new feature Review: pending Proposal is available for review labels Jan 23, 2026
@RexJaeschke
RexJaeschke marked this pull request as draft January 23, 2026 18:36
Comment thread standard/expressions.md
Comment on lines +7 to +13
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₁*.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Comment thread standard/variables.md Outdated
- 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*.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread standard/variables.md
Comment on lines +880 to +881
- 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.”

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@BillWagner
BillWagner force-pushed the v10-improved-definite-assignment branch from 2ff657f to 6da0f8f Compare March 24, 2026 19:26
Comment thread standard/variables.md
>
> *end note*

#### §isop-ispattern-expressions is operator and is pattern expressions

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@BillWagner
BillWagner force-pushed the v10-improved-definite-assignment branch from 6da0f8f to 3fa8a5c Compare April 14, 2026 19:15
BillWagner added a commit that referenced this pull request Apr 15, 2026
@BillWagner
BillWagner force-pushed the v10-improved-definite-assignment branch from 3fa8a5c to 672c696 Compare May 13, 2026 14:43
@BillWagner
BillWagner force-pushed the v10-improved-definite-assignment branch from 672c696 to 50f43d5 Compare June 24, 2026 19:00
@BillWagner

Copy link
Copy Markdown
Member

An earlier version of this feature is already present on alpha-v10 from a prior meeting. Edits made to this PR since then are not yet on alpha-v10; they will land at the next propagation. If you need them on alpha-v10 sooner, please open a separate PR targeting alpha-v10.
Thanks!

RexJaeschke and others added 5 commits July 24, 2026 15:51
`=> 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
@BillWagner
BillWagner force-pushed the v10-improved-definite-assignment branch from 50f43d5 to 36c3362 Compare July 24, 2026 19:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Review: pending Proposal is available for review type: feature This issue describes a new feature

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants