Note regarding thenew-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

Tagging subscribers to this area: @dotnet/area-system-runtime
See info inarea-owners.md if you want to be subscribed.

Out of interest, could this extend to having the comparers implementing IAlternateEqualityComparer<ReadOnlySpan, string> (or some new UTF8 ref struct wrapper) as well to allow for UTF-8 insertion within the same dictionary - as long as the hashes can be made consistent?

Out of interest, could this extend to having the comparers implementing IAlternateEqualityComparer `<ReadOnlySpan, string> (or some new UTF8 ref struct wrapper) as well to allow for UTF-8 insertion within the same dictionary - as long as the hashes can be made consistent?

Conceptually, yes. And you could certainly write your own comparer with any number of IAlternateEqualityComparer implementations for different TAlternate types (ReadOnlySpan<char>,ReadOnlySpan<byte>, etc.) We're not planning to do so on theStringComparers this release, and it's an open question whether we'd do so in the future. There are corner-cases such as what string isnew byte[] { 0xFF } equal to? Is it equal toEncoding.UTF8.GetString(new byte[] { 0xFF })? And if so, is it also equal toEncoding.UTF8.GetString(new byte[] { 0xFE }), since those produce the same strings? This brings policy into these core types, so while technically we can do it, it's a more complicated discussion.

Out of interest, could this extend to having the comparers implementing IAlternateEqualityComparer `<ReadOnlySpan, string> (or some new UTF8 ref struct wrapper) as well to allow for UTF-8 insertion within the same dictionary - as long as the hashes can be made consistent?

Conceptually, yes. And you could certainly write your own comparer with any number of IAlternateEqualityComparer implementations for different TAlternate types (ReadOnlySpan<char>,ReadOnlySpan<byte>, etc.) We're not planning to do so on theStringComparers this release, and it's an open question whether we'd do so in the future. There are corner-cases such as what string isnew byte[] { 0xFF } equal to? Is it equal toEncoding.UTF8.GetString(new byte[] { 0xFF })? And if so, is it also equal toEncoding.UTF8.GetString(new byte[] { 0xFE }), since those produce the same strings? This brings policy into these core types, so while technically we can do it, it's a more complicated discussion.

Agree yes it's not always obvious, but I'm glad it's flexible to support multiple implementations! Might only make sense with a validated UTF8 ref struct type. Thanks for the reply

I still need to do some perf validation. In particular, I tweaked the string hash code routines to accomodate span inputs (the existing logic took advantage of the \0 guarantee at the end of a string), and I need to see how much this impacts things and whether it'll instead be worth duplicating the functions to have one for string and one for span.

Unfortunately I couldn't quite get rid of the regression here for strings when using/updating a shared implementation, so I created a duplicate implementation of the two functions for span that returns the same hash value as for string but doesn't rely on the null terminator. I kept the slower non-ASCII fallback for both, but improved it to a) use a larger stack allocated buffer and b) not rehash all of the ASCII values leading up to the first non-ASCII value.

Should be good to go now.

Where can I read more about IAlternateEqualityComparer and its uses?