Open invidious9000 opened 4 years ago
FWIW, same on .NET Framework.
I agree it's not intuitive, but there's very little that can be done about this. The meaning of the -1 value as a timeout is entirely up to how the consumer is defined and interprets it. Changing the comparison operations to special-case that value would also be very unintuitive, and a massive breaking change.
TimeSpan remarks indicate that the value contained is some count of ticks, and this can be enough information to reason about the behavior, but the comparison operators seem to be a slightly more opaque implementation detail (you must look at source to see why it behaves this way).
Could this be considered a doc issue? I see that kinda-similar concerns were identified/discussed in https://github.com/dotnet/runtime/issues/30723#issuecomment-574308350
This really should be a doc issue demonstrating correct use of the existing Timeout API
Is there any value in augmenting documentation for InfiniteTimeSpan to explicitly indicate nuances around comparison or is it reasonable to expect consumers to infer these from tick remarks? Would the same suggestions advocating for IntelliCode enhancements as outlined in https://github.com/dotnet/runtime/issues/30723#issuecomment-526676911 apply?
Could it be appropriate to add a see-also for TimeSpan.MaxValue if that can sometimes be an acceptable substitute?
Thanks for the suggestions. Improving the docs is certainly possible! And we welcome contributions there, too. https://github.com/dotnet/dotnet-api-docs
Description
Timeout.InfiniteTimeSpan uses an internal representation of -1ms to define a period of infinite time. The operators for <, >, >=, <= in TimeSpan compare ticks between two instances. This leads to comparisons that seem invalid when naively using InfiniteTimeSpan (negative ticks) on one side of the comparison.
Example:
In this scenario
oneSecondIsLessThanInfinity
is false when one might expect it to be true..NET Core 3.1