C# Language Design Meeting for October 26th, 2022

Agenda

"Can you see this word I've highlighted?" "3..., 4..., 5..., 6..., 7..., 8..., 9..., 10..., 11..., 12..., 13..., 14..., 15! 15 second delay in the video"

Today we took a complete look at the proposal for null-conditional assignment. Overall, there were two points of concern with the feature:

Is the intuition around what a?.b = c(); actually does at runtime good? Most of the LDT was in agreement what the semantics of this would be without discussion, which is a good sign. However, a few members did say that their first read was that c() would be executed regardless of whether a was null. We think this is very similar to the reaction to ?. in C#, where many found the behavior intuitive, but a few users had to learn. We're therefore ok with the intuition of the behavior of this feature.
We took a look at nested scenarios, such as a?.b = c?.d = e?.f;, and thought about whether the semantics would be confusing. There are a few possible results from this nested assignment:
1. If a is null, nothing else will be evaluated.
2. If a is non-null and c is null, a.b will be assigned null and e?.f will not be evaluated.
3. If a and c are non-null, e?.f will be evaluated and the result will be assigned to c.d and a.b.
While we think this syntax form is probably not a good one, and we won't encourage users to use it, we think that it's a natural consequence of the way our grammar works, and don't see any good reason to forbid it.

The design is approved as is.