ContextQMD
Back to Csharplang

C# Language Design Meeting for July 17th, 2024

meetings/2024/LDM-2024-07-17.md

latest4.1 KB
Original Source

C# Language Design Meeting for July 17th, 2024

Agenda

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 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.