[API Proposal]: Add IEnumerator.CanReset

[koszeggy]

Background and motivation

Now that collection interfaces are being rationalized (even though the first attempt has been reverted) I would like to suggest a small fix that bothers me since .NET Framework 2.0, when yield return-like iterators rendered the IEnumerator.Reset() method unusable. The issue could have been mitigated by adding a bool CanReset property to the new generic IEnumerator<T> interface but it missed the opportunity.

I know that Reset() mainly exists to support COM compatibility and is not needed normally but as I created a lot of collections with custom enumerators it annoys me a bit that I usually implement the Reset() method but as there is no way to query whether it's usable it's better to avoid it anyway. The best I could do is just to mention everywhere in the documentation whether a collection's enumerator does or does not support the Reset() method, which is obviously a useless information when just handling the instance as a random IEnumerator.

API Proposal

Considering that also #31001 suggests using some default interface implementations, I also dare to suggest the following fix:

public interface IEnumerator
{
-   void Reset();
+   void Reset() => throw new NotSupportedException("To support the Reset() method implement it along with the CanReset property");
+   bool CanReset => false;
}

Please note that the default implementation is compatible with the yield return approach and does not force you to implement the Reset() method for explicit enumerators either.

API Usage

public class MyFancyEnumerator<T> : IEnumerator<T>
{
    private int _someSelfIndex;
    private IEnumerable<T> _someCollection;
    private IEnumerator<T> _someWrappedEnumerator;

    // [...]

    public void Reset()
    {
        _someSelfIndex = -1;
        if (_someWrappedEnumerator.CanReset)
            _someWrappedEnumerator.Reset();
        else // allocating a new instance
           _someWrappedEnumerator = _someCollection.GetEnumerator();
    }
}

Risks

Just by introducing this change all existing enumerators would return false for CanReset, even if they actually support it. Which actually isn't a breaking change; it just reflects the way we should consider Reset() today.

A future version of the .NET Analyzers simply could emit a warning for explicitly implemented enumerators if their Reset() method consists of something else than just throwing a NotSupportedException.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-linq
See info in area-owners.md if you want to be subscribed.

[eiriktsarpalis]

Introducing DIMs to existing interface types is something we have been wanting to do for a long time, but it's something that we simply haven't been able to find success in so far. The simple reason is that it's a type of change that fundamentally introduces all sorts of breaking changes and disruption, and this is doubly true for extremely popular types like collection interfaces. If we ever get around to making another attempt it would most likely be focusing on highly impactful improvements.

The case of Enumerator.Reset() is frankly not particularly impactful. It's largely a legacy API that newer collections don't implement and can easily be worked around by simply creating a new enumerator.