# C# Language Design Meeting for October 26th, 2022

## Agenda

- [Null-conditional assignment](#null-conditional-assignment)

## Quote of the Day

- "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"

## Discussion

### Null-conditional assignment

https://github.com/dotnet/csharplang/issues/6045

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

1. 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.
2. 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.

#### Conclusion

The design is approved as is.
