Have Breaking Changes in .NET 11?

[UniqeId6542]

I appreciate the language (and runtime when it's happened) backwards compatibility that c# / .NET has provided. But this also means that .NET slowly accumulates obsolete features. I'd like to see a large cleanup of these features at some point - and after more than 20 years of .NET, I think that we can afford a version with breaking changes. (And, I have a ton of thing's I'd like to request change.)

What: Get as many useful changes that would otherwise be excluded because they are 'breaking changes' into .NET 11. Then continue with the current rules about breaking changes for another 20 years.
Why .NET 11: Far enough in the future to give the community time to prepare and give feedback. .NET 10 should be a long term support .NET, so the version before the break will be supported for a while.

Examples (Not the point of this discussion, just to provide context. If support for breaking changes exists, then other discussions can be made for what to change.)

• Remove SyncRoot from ICollection
• IList to inherit from IReadOnlyList

[stephentoub]

There are breaking changes in every release of .NET, e.g.
https://learn.microsoft.com/en-us/dotnet/core/compatibility/8.0
https://learn.microsoft.com/en-us/dotnet/core/compatibility/7.0
https://learn.microsoft.com/en-us/dotnet/core/compatibility/6.0
etc.

IList to inherit from IReadOnlyList

This is on the docket for .NET 9; there's already a PR out for it. We'll see what kind of repercussions there are from it, and if it ends up being too breaking, in which case we'll roll it back before shipping .NET 9.

Remove SyncRoot from ICollection

Binary breaking changes like that are terrible for the ecosystem, e.g. any nuget package using it would stop working. I don't see us ever making such a change.

[tannergooding]

if possible to see if people consider the value worth the cost.

This will represent only a very small portion of the community. There are literally millions of .NET developers, ranging from hobbyist to large enterprises. There is also a very large amount of nuance around impact and insight to the problem that is not captured by people arbitrarily voting on whether or not they thing something is a good idea.

The core of .NET takes, and has always taken, a very strong stance on back-compat. The "one time" we did try to retro-fit the ecosystem with .NET Core 1.0 (and remove a bunch of legacy or no longer recommended APIs), it causd such a massive amount of pain that we brought almost all core APIs back by .NET Core 2.1 (and .NET Standard 2.0).

These APIs existing really harm nothing and it's not like people are implementing collection types so frequently that having this on the interface becomes painful to handle (nor is implementing it complex at all). So the cost to benefit ratio, over something like an analyzer recommending people not use the legacy API, doesn't justify it.

[tannergooding]

then people would just use the correct .NET target

This, for example, is missing the nuance around "roll forward". That things targeting .NET Standard 2.0 would no longer work on .NET vNext, that a package released for .NET 8 would no longer work on .NET 9 and would require the entire ecosystem to recompile.

This ends up being additional pain, overhead, and cost in terms of bandwidth, disk space, environmental impact, etc. All so users can avoid defining object ICollection.SyncRoot => this; (like List<T> does) if they happen to implement a collection type. Once you start doing this more broadly, it becomes even more painful and impactful.

[UniqeId6542]

This will represent only a very small portion of the community.

Certainly. But this is a forum that I can post in. Microsoft would be capable of reaching out to more people if they decided to.

we brought almost all core APIs back

While I am suggesting a larger set of changes, I'm not suggesting to necessarily delete a bunch of APIs. Or, they could be moved to optional NuGet packages.

it's not like people are implementing collection types so frequently

Please don't get hung up on my two examples. I did say that I had a ton of suggestions. Some may mean developers implement less, some may mean smaller core .NET dlls, some may mean less memory usage.

This ends up being additional pain, overhead, and cost

Yes. And I generally appreciate Microsoft taking the compatibility approach. But I also think that a major cleanup every couple of decades would be good. If the overall end result is easier and faster to code, then c# / .NET can stay a competitive language / framework for longer into the future.

[huoyaoyuan]

There are different categories of breaking changes:

1. Changes runtime behavior of specific methods/properties etc.
   These are acceptable because it can be dealed case-by-case in application code.
2. Prevents previously valid code from loading, throwing TypeLoadException or MemberNotFoundException.
   Removing any existing methods/types falls in to this. It's world-breaking and never acceptable. Instead, we hide/obsolete members to discourage user from them.

[tannergooding]

Certainly. But this is a forum that I can post in. Microsoft would be capable of reaching out to more people if they decided to.

Yes, and we have in the past. This is an area where we have over 20 years of input and lots of recent input/insight. It is not an area we are likely ever to change, especially at a broad scale.

The core of .NET does not remove APIs because it is ultimately worse for the ecosystem. There has to be an exceptionally good reason, such as the types causing fundamental security problems and which should never be used under any circumstances even in .NET Framework. But even then, we often prefer to keep the APIs and update them to throw NotSupportedException to avoid type load exceptions for code that isn't going to execute.

This is a hard stance that .NET takes and it is unlikely to ever change. Instead, the tooling is likely to improve to provide a better experience around hiding these APIs (stating they only exist for binary compatibility) and making it simple for users to not think about them if they are part of an interface or non-sealed class and a derived type would have to implement them.