# C# Language Design Meeting for July 17th, 2024

## Agenda

- [Overload resolution priority open questions](#overload-resolution-priority-open-questions)
- [Better conversion from collection expression with `ReadOnlySpan<T>` overloads](#better-conversion-from-collection-expression-with-readonlyspant-overloads)

## Quote of the Day

- "I don't know what shortstop is" "It's Abbott and Costello!" (proceeds to play Who's on First for the LDM during break)

## Discussion

### Overload resolution priority open questions

Champion issue: https://github.com/dotnet/csharplang/issues/7706  
PR: https://github.com/dotnet/csharplang/pull/8296

We started today by looking at a couple of open questions for overload resolution priority, to confirm and/or revise implementation decisions made by the feature. First, we looked at whether
to disallow the attribute on a few more locations. We'd [previously](LDM-2024-06-17.md#application-error-or-warning-on-overrides) decided that the attribute shouldn't be allowed in locations where
it would be an error to apply it. A few more locations came up during implementation. The only one of these that had mild discussion was local functions. However, ultimately, we decided that the
simple and pragmatic solution is to just disallow the attribute on local functions; even though they go through overload resolution, they do not allow overloads, so the attribute will have no impact.

Next, we looked at the desired behavior for language version. The proposal suggests 3 options for handling:

1. Don't have the attribute do anything when `LangVersion` is set to < 12.
2. Issue an error when the attribute impacts overload resolution behavior when `LangVersion` is set to < 12.
3. Silently honor the attribute when `LangVersion` is set to < 12.

Option 2 was discarded as a non-starter basically immediately, as it would block the runtime from adopting the feature. This leaves options 1 and 3. Option 1 better favors those who encounter the new
feature as they scout out new versions of VS for their coworkers, as it will ensure that new tooling versions continue to build their existing code exactly the same as it was. Option 3 better favors
those that upgrade to .NET 9, but keep themselves on C# 12 for the time being. After some discussion, we think that option 1 better serves the purpose of langversion, and will proceed with that approach.

#### Conclusion

We will error on all 5 locations: conversion operators, lambdas, destructors, static constructors, and local functions. We will ignore the attribute when the compiler is set to language version 12 or less.

### Better conversion from collection expression with `ReadOnlySpan<T>` overloads

Champion issue: https://github.com/dotnet/csharplang/issues/8297  
Related issue: https://github.com/dotnet/roslyn/issues/73857

Finally today, we took a look at what we could do around collection expression conversions to handle some issues that the BCL will be running into when they ship .NET 9. New overloads of `string.Concat`
can break collection expressions because we don't have a betterness tiebreaker around `ReadOnlySpan<T>` vs `ReadOnlySpan<U>`, and first-class spans can't serve this gap because collection expressions have
a different preferred span type than the rest of the language.

Discussion in LDM showed a general reluctance to go with the narrow proposal, and we much preferred the version that applied better conversion from element recursively to solve this problem. That version
gets us closer to unification with `params` collections and is more complete. While we do think this will be a problem in .NET 9, we're hopeful that we can use `OverloadResolutionPriorityAttribute` to solve
the BCL issues. We'll therefore take this back and verify that `OverloadResolutionPriorityAttribute` can solve this in a way that is acceptable; if it can't, then we can pick this back up and make a decision
on what to do here in the short term, or whether we should pull the methods from the BCL for .NET 9.

#### Conclusion

We will look at `OverloadResolutionPriorityAttribute` to solve this for .NET 9, and then look at the more comprehensive better conversion approach for a future release.
