[cfe-dev] [libcxx] Extending the behavior of std::hash in libc++

Geoffrey Romer via cfe-dev cfe-dev at lists.llvm.org
Tue Nov 24 15:02:31 PST 2015


Hi-

tl;dr: I'd like to extend libc++ to provide some way of customizing the
behavior of std::hash. How can I make that happen?

My overall goal is to make it possible for projects using libc++ to use the
hashing framework described in P0029 [1]. A lot of that framework can be
implemented in userland, but there's one part that necessarily touches the
standard library: it alters the behavior of the std::hash primary template
and the standard-defined specializations. So I'd like to add some sort of
extension point in libc++ to allow user code to customize std::hash
correspondingly.

The most obvious way to do this, and my preferred solution, would be to
actually implement P0029 in libc++ (obviously controlled by some sort of
opt-in flag). However, other more generic approaches are also possible,
e.g. providing some hook to allow user code to swap in an arbitrary
implementation of std::hash. Such an approach would require much less
up-front code, and would provide more flexibility, but the fact that it's
less constrained could make it more open to abuse.

What's libc++'s policy on extensions? Does Clang's policy on language
extensions [2] apply to libc++? If so, I think my proposal scores well on
the criteria outlined there:
1. Evidence of a significant user community: the reason I want this is so
that I can deploy it in Google's internal codebase, where it would be used
by thousands of developers. Furthermore, the reasons we want it (making it
easier to make types hashable, and providing protection against hash
flooding) are broadly applicable, so it seems likely that others will adopt
this extension as well.
2. A specific need to reside within the Clang tree: as discussed, the
proposal involves changes to std::hash, and that can't be done from the
outside; it has to be integrated into libc++.
3. A complete specification: see P0029. I do expect that specification to
keep evolving, but not to become less complete.
4. Representation within the appropriate governing organization: P0029 is
making active progress toward standardization, and indeed one of my
secondary goals here is to gain implementation and usage experience with
it, which can feed back into the standardization process.
5. A long-term support plan: deploying this new hashing framework, and
keeping it working once it's deployed, is a major part of my day job and a
top priority for my team. We're going to support it, because we're going to
deeply depend on it.
6/7. A high-quality implementation and a proper test suite: Obviously these
don't exist yet; I'll have to make my case on these grounds once I have
code to review.

What are your thoughts? Also, who actually makes the decision on this?

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0029r0.html
[2] http://clang.llvm.org/get_involved.html#criteria
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20151124/1d652ca3/attachment.html>


More information about the cfe-dev mailing list