Orthogonal "when" dimension for assertions?

[julealgon]

Some assertions can either happen "now", or "after a certain time", or "within a certain time".

Here are some examples:

Task<AndConstraint<TAssertions>> CompleteWithinAsync(TimeSpan timeSpan) {}
Task<AndConstraint<TAssertions>> NotCompleteWithinAsync(TimeSpan timeSpan) {}
Task<AndConstraint<TAssertions>> NotThrowAfterAsync(TimeSpan waitTime, TimeSpan pollInterval) {}
Task<ExceptionAssertions<TException>> ThrowWithinAsync<TException>(TimeSpan timeSpan) {}

Because this "time" dimension is added directly to each individual assertion, new overloads have to be created for each combination. Looking from the outside, this seems suboptimal to me.

Would it be possible instead to model this time window dimension separately, in a way that can be chained/combined to other calls in a more orthogonal fashion?

So instead of

.Should().ThrowAsync<TException>()
.Should().ThrowWithinAsync<TException>(TimeSpan timeSpan)

We'd have:

.Should().ThrowAsync<TException>()
.Should().ThrowAsync<TException>().Within(TimeSpan timeSpan)
or
.Should().ThrowAsync<TException>(c => c.Within(TimeSpan timeSpan))
or
.Should().Within(timeSpan, c => c.ThrowAsync<TException>())
or 
.Should().Within(timeSpan).ThrowAsync<TException>()
or even... 
.Within(timeSpan).Should().ThrowAsync<TException>()

Thoughts?

This started as a comment on:

• Missing ThrowWithinAsync similar to CompleteWithinAsync #2034

[dennisdoomen]

Should().ThrowAsync<TException>().Within(TimeSpan timeSpan) is going to be a bit harder to pull off, since you don't really know whether the ThrowAsync call is going to be succeeded by a Within call. I know you can do some smart things by implementing GetAwaiter.

Should().ThrowAsync<TException>(c => c.Within(TimeSpan timeSpan)) would be easier to implement.

But changing this would require us to go through every API supporting some time element and then defining the new signature. And obviously all of this will become a breaking change.

[julealgon]

Regarding the breaking change aspect, it could be done in a way where both APIs are initially offered and the old one is marked as [Obsolete] for one/few releases, then removed later.

[dennisdoomen]

That would require us to maintain multiple versions of the API for a potentially very long time. We only introduce breaking changes every few years.