Should Dictionary<TVey, TValue>.Keys collection be comparer-agnostic?

[arsenmk]

Today I came to a surprise writing a unit test to verify some keys are present in my dictionary and some are not. The surprising part was that when I searched for a key that the Keys did not contain*, it turned out it contained it. The asterisk is there because I used StringComparer.OrdinalIgnoreCase for the dictionary. Here's the essence of my code:

using System;
using System.Collections.Generic;
using System.Linq;

public class Program
{
	public static void Main()
	{
		Dictionary<string, string> values = new(StringComparer.OrdinalIgnoreCase)
		{
			{"key1", "value1"}
		};
		Console.WriteLine(values.ContainsKey("KEY1")); // prints 'true'
		Console.WriteLine(values.Keys.Contains("KEY1")); // prints 'true'

		var keysArray = new string[1];
		values.Keys.CopyTo(keysArray, 0);
		Console.WriteLine(keysArray.Contains("KEY1")); // prints 'false'
	}
}

If I called Dictionary.ContainsKey, I wouldn't be surprised by this result, because I chose the comparer explicitly. But when I use the Keys collection, I do not expect it to be aware of the comparer, and nothing in the public documentation of the Dictionary<Tk,Tv>.KeyCollection class says that it is. Only after hitting this result, and then checking the source code of that class I realized why it works that way.

Now I kind of wonder if this is by design. If so, I believe the documentation should contain at least some hint that Keys property is aware of the comparer. Although, again, by explicitly adding keys to the dictionary, and then checking what I added, I still do not expect the comparer to be in play.

[colejohnson66]

IMO, it's understandable for it to work that way, but it is surprising. I'd argue it's a documentation bug then, but that's just me. https://github.com/dotnet/dotnet-api-docs/blob/main/xml/System.Collections.Generic/Dictionary%602+KeyCollection.xml

[arsenmk]

I feel like there is still something controversial, not just a documentation issue. Semantically, it doesn't make sense to me that Keys contains a value, but when I take a copy of the Keys it doesn't contain that value anymore.

[elgonzo]

nothing in the public documentation of the Dictionary<Tk,Tv>.KeyCollection class says that it is

I'd argue it's a documentation bug then, but that's just me.

I beg to differ. From the documentation of the KeyCollection's Contains method: "Implementations can vary in how they determine equality of objects; for example, List<T> uses Default, whereas, Dictionary<TKey,TValue> allows the user to specify the IComparer<T> implementation to use for comparing keys."

it doesn't make sense to me that Keys contains a value, but when I take a copy of the Keys it doesn't contain that value anymore.

By the same reasoning, any collection type that allows using a user-defined comparator for managing its items (like a HashSet or SortedSet, for example) shouldn't make sense to you either, as these in the same manner can "contain" values that a copy of it doesn't "contain" anymore...

[arsenmk]

Hmm, didn't see that remark in the doc, thanks for finding it.

By the same reasoning, any collection type that allows using a user-defined comparator for managing its items (like a HashSet or SortedSet, for example) shouldn't make sense to you either, as these in the same manner can "contain" values that a copy of it doesn't "contain" anymore...
Maybe you're right, my perception is still conflicting with your reasoning, but that might be because I haven't used this class enough.