Skip to content

Latest commit

 

History

History
52 lines (37 loc) · 4.07 KB

LDM-2024-08-28.md

File metadata and controls

52 lines (37 loc) · 4.07 KB
Raw

C# Language Design Meeting for August 28th, 2024

Agenda

Quote of the Day

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

Discussion

Nullable in ref ternaries

Issue: #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: #3037
Related issue: #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 #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.