Repeated class is misleading

A verification of IReturnValueArgumentValidationConfiguration<T>.MustHaveHappened(Repeated.Exactly.Once) in the English language, this means that the call must have happened twice; once, then repeated exactly once. Recommend changing the name of this Repeated class to Executed or something so there’s no confusion.

[blairconrad]

MustHaveHappenedANumberOfTimesMatching(IsPrime) // where IsPrime is a method group

I’d drop this. It’s not supported now, and wouldn’t produce good failure messages anyhow. If a call to a helper predicate is needed, we should rely on

MustHaveHappenedANumberOfTimesMatching(n => IsPrime(n))

[blairconrad]

@thomaslevesque and I went off and chatted about possible replacements for Repeated. Here’s an API we’re considering:

MustHaveHappened()    // as today
MustNotHaveHappened() // as today

MustHaveHappenedOnceExactly()
MustHaveHappenedTwiceExactly()
MustHaveHappened(3, Times.Exactly)
MustHaveHappened(3, Times.OrMore)
MustHaveHappened(3, Times.OrLess)

MustHaveHappenedANumberOfTimesMatching(n => n %2 == 0)
MustHaveHappenedANumberOfTimesMatching(IsPrime) // where `IsPrime` is a method group

Times would be a new static class.

We like this approach because

1. MustHaveHappened() and MustNotHaveHappened() stay, and they should be by far the most popular of these kinds of methods in use today
2. It eliminates (I think) the confusion over the exact semantics of Repeated
3. It improves discoverability, even over the existing Repeated mechanism
4. We don’t have to invert the natural order of words (e.g. Times(3)), nor add an extension method to int

And we can also supply a soft transition: the Repeated variants can live for a major release or two, likely deprecated in 5.0.0 and removed in 6.0.0. In the interim, the documentation can be updated to push users to the new format, either ignoring the old one or explicitly mentioning Repeated as a legacy approach.

Accordingly, I’m reopening the issue. Comments welcome.