2.6.1: Ambiguous call errors for Assert.Contains<T>(T, ISet<T>) and Assert.Contains<T>(T, IReadOnlySet<T>)

[craigktreasure]

After attempting to upgrade from 2.5.2 to 2.6.1, I received errors about ambiguous calls for Assert.Contains and Assert.DoesNotContain:

• error CS0121: The call is ambiguous between the following methods or properties: 'Assert.DoesNotContain<T>(T, ISet<T>)' and 'Assert.DoesNotContain<T>(T, IReadOnlySet<T>)'
• error CS0121: The call is ambiguous between the following methods or properties: 'Assert.Contains<T>(T, ISet<T>)' and 'Assert.Contains<T>(T, IReadOnlySet<T>)'

This occurs for a set type that implements both ISet<T> and IReadOnlySet<T>, like HashSet<T>.

Example that previously worked:

SetAndReadOnlySet<int> set = new()
{
    1,
    2,
};

Assert.Contains(1, set);
Assert.DoesNotContain(0, set);

You can of course workaround by casting the set to either an ISet<int> or IReadOnlySet<int>, which is what will be necessary if this breaking change was intended.

[bradwilson]

Unfortunately there's not much we can do about compiler ambiguity. We have overloads for the common concrete types, but when using a third party concrete type, you'll either have to ensure variables are of a non-ambiguous type, or extend the assertion library to include your custom concrete type(s).

https://github.com/xunit/assert.xunit/blob/cb1e33ba612d4829e0848a44bde1026f5f9e3576/SetAsserts.cs#L68-L92

[craigktreasure]

Unfortunately there's not much we can do about compiler ambiguity. We have overloads for the common concrete types, but when using a third party concrete type, you'll either have to ensure variables are of a non-ambiguous type, or extend the assertion library to include your custom concrete type(s).

https://github.com/xunit/assert.xunit/blob/cb1e33ba612d4829e0848a44bde1026f5f9e3576/SetAsserts.cs#L68-L92

To be clear and as noted in the OP, the HashSet<T> type, which is not third-party, will also have this issue as it implements ISet<T> and IReadOnlySet<T>.

[bradwilson]

No, HashSet<T> has a concrete overload already, as I linked to. We have tests that show it works without casting. Example:

xunit/src/xunit.v3.assert.tests/Asserts/SetAssertsTests.cs

Lines 17 to 19 in b9a547c

	var set = new HashSet<string>(StringComparer.OrdinalIgnoreCase) { "forty-two" };
	Assert.Contains("FORTY-two", set);

[craigktreasure]

No, HashSet<T> has a concrete overload already, as I linked to. We have tests that show it works without casting. Example:

xunit/src/xunit.v3.assert.tests/Asserts/SetAssertsTests.cs

Lines 17 to 19 in b9a547c

	var set = new HashSet<string>(StringComparer.OrdinalIgnoreCase) { "forty-two" };
	Assert.Contains("FORTY-two", set);

Ah! I missed that. Thanks for the clarification.

[AndriySvyryd]

This is still an issue for SortedSet<>, and ImmutableSortedSet<>