NoSenseEtAl
NoSenseEtAl

Reputation: 30128

Why C++20 knows how to hash string_view, but does not know how to hash span<char>?

My best guesses are that committee either forgot about this use case or did not want to use concepts/requires to restrict the span type to something that can be safely hashed(POD, no padding), or they did not want half solutions(waiting for reflection)...

If somebody is interested here is godbolt link with unhelpful error messages and code, but I presume my question is clear without any code.

#include <span>
#include <unordered_set>
#include <string_view>
int main() {
    std::hash<std::string_view> h1;
    std::hash<std::span<char>> h2; // error here
}

note: I know C++ std:: library is lacking in cases when it comes to hashing, e.g. it can not hash std::pair<int,int>, but my question is in particular about the std::span.

Upvotes: 6

Views: 1072

Answers (1)

Nicol Bolas
Nicol Bolas

Reputation: 474266

string_view is very definitely a string; a span<char> is just an array of chars. It could have the same conceptual meaning as a string_view, but you cannot say that this is inherently true of the type. And therefore, it is not reasonable for the standard to assume that every span<char> ought to be treated equivalently to a string.

Most containers don't have standard-defined hashing (the string containers being the only exception). The reason being that there's not a good default hash algorithm for a sequence of Ts. And even if there was, span<char> using that algorithm almost certainly wouldn't produce the same hashed value as a string_view.

Furthermore, the two types treat equivalency differently. string_view has an operator== overload; span<T> does not. Hashing is conceptually based on equality: if two objects compare equal, then the hashes produced by those objects must be equal. But since span has no equality testing at all, hashing a span makes little sense.

Upvotes: 2

Related Questions