Skip to content

Latest commit

 

History

History
44 lines (29 loc) · 3.01 KB

File metadata and controls

44 lines (29 loc) · 3.01 KB

C# Language Design Meeting for April 7th, 2025

Agenda

Quote of the Day

  • "We can have multiple arguments about it, further down the road"

Discussion

Breaking change discussion: making partial members in interfaces virtual and/or public

Breaking change: Compiler breaking changes
Pull request: dotnet/roslyn#77379

First up today, we looked at a potential bugfix for a longstanding behavior, since enhanced partial members were introduced into the language. This behavior was initially noticed when implementing partial events, and further investigation has shown that it affects all partial members in interfaces. While we don't like this inconsistency, we also don't think this behavior is particularly affecting anyone; we were the ones to discover it, rather than a bug being reported, and the behavior in methods has been around for a long time. While we're fine with what is effectively a bug fix for partial properties, which have not been out for long, we're not of the opinion that changing the behavior for partial methods in interfaces is worth the effort or risk potential. Instead, we'd rather just leave that as is.

Conclusion

We will take this bugfix for partial properties and events, but not for methods. Since partial properties are so new, we will not tie it to language version unless divisional breaking change procedures require us to do so.

Interpolated string handler argument values

Champion issue: #9046
Specification: https://github.com/dotnet/csharplang/blob/4df926c14494c5990bd1c27380180eab90c56cb3/proposals/interpolated-string-handler-argument-value.md

Following up from February 24th, we have a new proposal around how to pass constant values to interpolated string handlers for parameterization. This version of the proposal allows passing a single constant value via the attribute, which will be added after anything passed via InterpolatedStringHandlerArgumentAttribute. We thought about whether we would want to support multiple values, but we currently don't have any scenarios that need such capabilities, and we don't want to design that without a use case to validate the design against. To ensure that we have future ability to design this, though, we will disallow arrays as arguments, in case that is the approach we decide to take in the future.

Conclusion

Proposal is approved. Arrays are disallowed as argument values to preserve design space.