IEnumerable.GetEnumerator with default implementation

[dellamonica]

The generic IEnumerable interface inherits from the (legacy) non-generic IEnumerable. They both have GetEnumerator methods which differ on the return type by the generic vs non generic versions of IEnumerator. Anytime someone needs to implement IEnumerable (and I imagine essentially no-one works with the non-generic collections at this time) it is also necessary to implement the non-generic version for backwards compatibility polluting the code with outdated concepts.

The question here is: couldn't the BCL be updated so that the non-generic version has a default implementation which just calls the generic version?

[HaloFour]

See: dotnet/runtime#29513

[dellamonica]

But how would this work here with IEnumerable? IEnumerable inherits from it.

On a high level, both "legacy" and "modern" packages would both define the interface IEnumerable<T> but on the "modern" package IEnumerable would not be defined and thus IE<T> would not inherit from it.

Namespaces and shims could be used to bridge the gap when upgrading. So maybe if you recompile a project trying to use a modern version but with some dependency that relies on the legacy types, those dependencies would have a shim that replaces the namespace of the legacy types to something like System.Legacy.NonGeneric where IEnumerable and friends are defined.

Not sure how well this would work but you could define an interface S.L.NG.IEnumerable<T> that inherits both from the modern IEnumerable<T> and the legacy IEnumerable, which means that any type implementing the "legacy" IEnumerable<T> in the dependency would be compatible with the client's code that uses the modern package.

people don't want a fine grained set of packages they have to then navigate.

Agree, but you don't need a toggle for every little bit, you could have simply a "modern" and a "legacy" version for each dotnet release, and what is removed from the legacy version can evolve with the releases. Many people won't mind keeping all the legacy stuff around, so they won't have to worry about anything.

[CyrusNajmabadi]

Namespaces and shims could be used to bridge the gap when upgrading.

Sicne all those work has to be done. It just means that things are more complex anyways, and potentially even confusing and error prone for users. Just having the type exist in its current state and continue working means people don't have to run into this, the costs are zero, and the risk are as well.

[dellamonica]

Sicne all those work has to be done. It just means that things are more complex anyways, and potentially even confusing and error prone for users. Just having the type exist in its current state and continue working means people don't have to run into this, the costs are zero, and the risk are as well.

Again, not arguing that this is worthy it for this specific case, you may as well be entirely correct in the cost-benefit analysis. However, not having any decent strategy for deprecating code in the BCL is IMO a flaw of dotnet. As you said, it's 25 years old and it will only get older. I'll concede that the dotnet community efforts to make trimming better in the recent years at least helps to remove the old stuff from published binaries.

[CyrusNajmabadi]

We do deprecate things. But generally with a cost/benefit/risk assessment that warrants it being worthwhile. I think where there is disagreement here is on the enormity of the risk. You're talking about what could literally be described as one of the top 10 types in all of .net. It would be akin to changing int32, or string. etc. Such a change is going to need very large benefit, or just huge assurance that it's going to be safe to make it worthwhile. Absent that, it's not going to happen as there is just likely to be real pain given the numbers we're talking here, and only very marginal benefit.

[dellamonica]

For good or bad, dotnet is very conservative with respect to deprecation.

I'm not sure I'll follow up with the runtime team as the only feasible plan I could come up with for general deprecation of such fundamental types as IEnumerable does seem very costly in terms of tooling and friction with the user base.

Thank you all for this nice discussion.

[dellamonica]

It seems clear to me you are not gonna make a move on this, so feel free to close the discussion

We're not going to move on this in the short term. But the discussion is relevant and valuable for the long term. For context, we're already 25 years old. We have to think and plan over those sorts of timescales :)

Yeah, I know, I've been using C# for almost that long.

however, I really think the language team should have a strategy

This is not part of the language. You can def send that feedback to the runtime though :)

I think it needs some support from the language, even if in the form of analyzers, but sure, the runtime needs to be worked on, not sure I have a concrete model for the more general idea of removing obsoleted parts of the BCL from "fresh" codebases. Let me think and write about it and I will link it up here.

to get rid of the legacy cruft in the language.

One person's 'legacy cruft' is another person's invaluable base that they depend on. We have ample experiences with breaking changes and the benefits/costs around there. Right now this isn't crossing the necessary hurdle to make it worthwhile. That may change in the future.

Most people would agree that the non-generic collections are legacy cruft, and for those that depend on it still, they are surely not targeting .net 8.