# C# Language Design Meeting for August 28th, 2024

## Agenda

- [Nullable in `ref` ternaries](#nullable-in-ref-ternaries)
- [Block-bodied switch expression arms](#block-bodied-switch-expression-arms)

## Quote of the Day

- "I want to go meta meta for a second"

## Discussion

### Nullable in `ref` ternaries

Issue: https://github.com/dotnet/csharplang/issues/8379

First up today, we looked at an issue that was originally raised as a Roslyn bug; nullable suppression of `ref` ternaries didn't work as expected. In fixing this bug, our testing showed
that the experience was not very polished overall, and should be revisited to be more consistent. One important note about this is that the original bug _is_ a compiler bug; a nullable
warning was being reported, but it couldn't be suppressed. However, we think this is a good opportunity to align `ref` ternaries with both regular ternaries, and method argument behavior.
Given that, we decided to go with option 1: use best common type and type inference.

#### Conclusion

Go with proposed option 1, using best common type and type inference.

### Block-bodied switch expression arms

Champion issue: https://github.com/dotnet/csharplang/issues/3037  
Related issue: https://github.com/dotnet/csharplang/issues/3086

Finally today, we took a look at an older issue that occasionally comes up, to see if we wanted to make any more progress on it in the nearer term. Switch expression arms, and by extension
any expression location, occasionally want to have side-effects. These often force users to fall back to much more verbose patterns; moving to a switch statement, rewriting an expression
into a series of multiple statements, etc. While the specific issue we discussed today is only for switch expressions, it really is a backdoor to the whole space, as we need to design far
enough ahead to know how the whole space would work. Otherwise, we'd risk ending up in a space where we have diverging statement-within-expression syntaxes, which is something we absolutely
want to avoid. Ultimately, the LDM is very much in favor of continuing to explore this space, but we're far less unified on the specifics. We discussed a few different possible syntaxes for
the "produce a value from this expression block":

* `break value` - as in the proposal. This has some advantages in not being legal syntax today, but some members are concerned about the confusion it could bring if you mix `break`, `break value`,
  and `continue`. There's also some concern that it is not intuitive as to what is actually happening.
* `return value` - an alternate option that would make `return` mean something different when in an expression block. Some members mentally model expression blocks as lambda expressions that
  are immediately invoked, and this interpretation naturally complements this. However, other members are concerned that it implies that the user will leave the method, not the containing
  expression block, and that it would also block the ability to actually do just that.
* `out value` - like `break`, this has the advantage of not being legal syntax today in the locations you'd use it. But, like with break, there's concern about how understandable of a keyword
  it is.
* No keyword - As in https://github.com/dotnet/csharplang/issues/3086, we could also just leave the last `;` off a statement and have that be what the block evaluates to. There's some compelling
  examples of this in the real world already, such as Rust or F# (F#'s `|> ignore` is the equivalent of a more obvious `;` in this case). But there's some concern about the subtlety of this,
  and whether it would force users to write expression blocks in a particular pattern; how might a user produce a value from the middle of a `foreach` if they found the value they're looking
  for, for example.

Ultimately, we are far too fractured, and talking about too many hypotheticals, to make a decision today. We need to go back and do more research; look at other languages that have concepts like
this and see what they do, how their solutions might apply to C#, and come up with sets of examples around it to inform our decision making.
