Joseph Musser

@JakeGinnivan is not a Shouldly org member and is not in @shouldly/core. Should he be removed as an active maintainer, for example from being able to push NuGet packages? We...

Most specialized ShouldBe overloads do not support null arguments by design. For example, null tasks, null strings, etc. We could reconsider this and it would require some design work to...

I agree, and yet practically speaking it's so nasty on a regular basis.

Debugging a test stops you in an inappropriate stack frame whenever an assertion fails. That happens at a rate far beyond any other library I can think of in the...

That's for sure. A both-and strategy solves the immediate need, and also helps people who don't stay on (or can't use) the latest VS all the time.

I accidentally regressed this same thing in NUnit and fixed it after discussion. If it's a potentially catchable/recoverable exception, it's best practice to return a failed Task object to the...

There is not a clear way to solve this. We would have to special-case certain types and that would be a big break from previous behavior, which has legitimate uses....

With other types you would unwrap this way: ```cs collectionOfHashsetsA.ShouldHaveSingleItem().ShouldBe( collectionOfHashsetsB.ShouldHaveSingleItem()); nullableOfImmutableArrayA.ShouldNotBeNull().ShouldBe( nullableOfImmutableArrayB.ShouldNotBeNull()); ``` But since Shouldly doesn't bring a dependency on F#, we can't ship an unwrapping method specifically...

This is in principle the same as https://github.com/shouldly/shouldly/issues/767 only with FSharpOption instead of Dictionary.

I would start by copying the existing test pattern, e.g. https://github.com/shouldly/shouldly/blob/master/src/Shouldly.Tests/ShouldBeUnique/IntegerArrayScenario.cs.