Create a version of `SatisfyRespectively` that ignores order

Description

The SatisfyRespectively method is a great way to validate fixed elements in a collection, and I’ve been using it extensively since it was recently introduced.

However, I’ve come across a few cases where I want to perform the checks on all elements on a sequence, but I don’t care about the order that they are returned (as long as they match the exact amount of assertions and only once each).

I’d like to propose the creation of a variation of SatisfyRespectively that ignores the order where the assertions are found in the collection, but otherwise work similarly.

Example

// Arrange
var numbers = new [] { 1, 2 };

// Assert
numbers.Should().SatisfyDistinctly(
    n => n.Should().Be(2),
    n => n.Should().Be(1));

I used the name SatisfyDistinctly here as Distinctly was the first logical antonym of Respectively that I found, but any fitting name would suffice.

[siewers]

I know what it means, but only after looking it up 😉 I just believe it would have been a lot easier for non-native English speakers to understand if it was named SatisfyInOrder instead of SatisfyRespectively. That would also fit with the already existing ContainInOrder, which is not called ContainRespectively. To my knowledge, there are no other instances in the library, where Respectively is used, which also makes it a bit unnatural to look for. I actually don’t even recall ever encountering a method containing that word 😃

The documentation doesn’t even say it’s evaluated in order either (as I understand it):

Asserts that a collection contains exactly a given number of elements, which meet the criteria provided by the element inspectors. The element inspectors, which inspect each element in turn. The total number of element inspectors must exactly match the number of elements in the collection.

So maybe a simple improvement would include that the element inspectors will be matched against the exact order of the collection?

To me, there is a big difference about being correct in the dictionary definition compared to a more common used term already used in the library and in the entire framework 😃

[julealgon]

…if it was named SatisfyInOrder instead of SatisfyRespectively. That would also fit with the already existing ContainInOrder, which is not called ContainRespectively.

This is a great point IMHO. Having methods that behave similarly in the API but are named differently is bad for consistency/discoverability.

The rename to SatisfyInOrder does make quite a bit of sense to me as well, even if I myself knew what the “Respectively” meant originally.