runtime: Add TimeSpan.Infinite

We already have System.Threading.Timeout.InfiniteTimeSpan, which uses -1 for milliseconds.

@KrzysztofCwalina proposed to add an alias under TimeSpan which would be more discoverable:

I think it would be useful. The Timeout type is in Threading namespace and we don’t want to use it as timing out has nothing to do with threading.

Proposed API

namespace System
{
    public partial struct TimeSpan
    {
        public static readonly TimeSpan Infinite = System.Threading.Timeout.InfiniteTimeSpan;
    }
}

About this issue

Original URL
State: closed
Created 5 years ago
Reactions: 9
Comments: 21 (20 by maintainers)

Most upvoted comments

When a users sees TimeSpan parameter, they might try to see if there is a singleton property in TimeSpan (just like there are singleton properties on all our primitive types), but it will never cross their mind to go look into some other type in a different namespace.

So let’s update the documentation for TimeSpan to highlight Timeout.InfiniteTimeSpan. Let’s augment IntelliCode to suggest Timeout.InfiniteTimeSpan when IntelliSense pops up to offer options for TimeSpan arguments. Let’s have an analyzer that flags use of -1 for timeout arguments and suggest using a TimeSpan overload with Timeout.InfiniteTimeSpan instead. Etc. There are other ways to address such concerns than adding a new such property, which I continue to maintain is the wrong thing to do. (If I’m outvoted and we decide to add such a property, I maintain it must be the equivalent of InfiniteTimeSpan, and have a name that makes it clear it’s a synonym, e.g. InfiniteTimeout, with the docs and IntelliSense being super clear about the association.)

I think it would be reasonable to not waste time creating timers when the calling code passes 30K years timespan.

What cut-off is reasonable? And who’s on the hook to go update all code in .NET Core and all customer code to factor in the new cut-off?

stephentoub on Aug 30, 2019

I don’t love it or think it’s necessary, but to quote from myself above:

If I’m outvoted and we decide to add such a property, I maintain it must be the equivalent of InfiniteTimeSpan, and have a name that makes it clear it’s a synonym, e.g. InfiniteTimeout, with the docs and IntelliSense being super clear about the association.

stephentoub on Sep 4, 2019

I don’t think would be objectively bad

I think it would be bad. Every API that currently special-cases Timeout.InfiniteTimeSpan would be wrong. That “wrong” may not manifest as correctness; it could easily manifest as a performance issue. For example, if HttpClient.Timeout is Timeout.InfiniteTimeSpan, then the implementation avoids creating a bunch of things, including a Timer, for each request; using this mythical TimeSpan.Infinite instead of Timeout.InfiniteTimeSpan would make everything more expensive.

I think we’re making a mountain out of a mole hill. There may be a minor discoverability issue with Timeout.InfiniteTimeSpan living in System.Threading… is that the only concern here? To me, that doesn’t justify adding a new incorrect API.

stephentoub on Aug 30, 2019

I agree we cannot keep using -1 in this case

I don’t see how such a new property could have a value different from Timeout.InfiniteTimeSpan. It’s not just about a new property and new methods, but every existing method that takes a TimeSpan and special-cases this one value.

stephentoub on Aug 30, 2019