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

[Geoffrey Romer via cfe-dev]

Bump. We've had some useful side discussion, but no answers to my original
questions.

On Tue, Nov 24, 2015 at 3:02 PM, Geoffrey Romer <gromer at google.com> wrote:

> 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/20151211/f0dbf03f/attachment.html>