# C# Language Design Meeting for April 7th, 2025

## Agenda

- [Breaking change discussion: making partial members in interfaces virtual and/or public](#breaking-change-discussion-making-partial-members-in-interfaces-virtual-andor-public)
- [Interpolated string handler argument values](#interpolated-string-handler-argument-values)

## 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](https://github.com/dotnet/roslyn/blob/db643157d8c64d47beb0a7d627244629a5116cd1/docs/compilers/CSharp/Compiler%20Breaking%20Changes%20-%20DotNet%2010.md#extended-partial-members-are-now-implicitly-virtual-and-public)  
Pull request: [dotnet/roslyn#77379](https://github.com/dotnet/roslyn/pull/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: https://github.com/dotnet/csharplang/issues/9046  
Specification: https://github.com/dotnet/csharplang/blob/4df926c14494c5990bd1c27380180eab90c56cb3/proposals/interpolated-string-handler-argument-value.md

Following up from [February 24th](./LDM-2025-02-24.md#interpolated-string-handler-method-names), 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.
