Reputation: 30128
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
Reputation: 474266
string_view
is very definitely a string; a span<char>
is just an array of char
s. 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 T
s. 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