Closed WhitWaldo closed 5 months ago
While one can generally use newer versions of C# with older .NET runtime versions, some C# features require a certain .NET minimal runtime version and those cases can be subtle. I might be ok with bumping up the language version for an internal project as it has a much smaller audience, but for an OSS project I'm hesitant to break from Microsoft's stated requirements. What can I say--I've always been a rule follower. :-)
I'd be ok with considering support for .NET 7 deprecated as of (the imminent) 1.14 release. For .NET 6, depending on the timing, we may be able to consider its support deprecated with the 1.15 release. That would mean .NET 8 becoming the minimally supported version thereafter, for which we can then bump up the language version to C# 12.
I'm dying to use all the new snazzy features of C# 12, too, but I think we need to hold on just a bit longer for the Dapr .NET SDK.
That's fair. I didn't think about language-specific dependencies on frameworks.
I think the timing makes sense. The 1.15 release can be tested with the preview bits of .NET 9 (it should probably at least merit a test suite even if it's not officially supported) and be ready for Day 1 support and transition to .NET 8 as the new LTS base with C# 12.
Thanks for chiming in!
Describe the proposal
I would like to propose that the .NET SDK adopt a policy of explicitly targeting the latest C# language version across all SDKs as opposed to inherently supporting the minimal language introduced with the oldest framework being targeted (currently targeting C# 10 via the support for .NET 6 where the latest is currently on C# 12).
We shouldn't be targeting any of the preview language versions as that would introduce headaches to maintain and introduce reliability concerns, but by supporting the latest languages, we can continue to debate the EOL strategy around older frameworks while still allowing the syntactic sugar of recent releases.
By supporting the most recent language by default, this has at least three noted benefits:
is not null
instead of!= null
, we get the compiler guarantee that won't inadvertently utilize any user-overloads of!=
or==
).