<div dir="ltr">Bump. We've had some useful side discussion, but no answers to my original questions.</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 24, 2015 at 3:02 PM, Geoffrey Romer <span dir="ltr"><<a href="mailto:gromer@google.com" target="_blank">gromer@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi-<div><br></div><div>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?</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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:</div><div>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.</div><div>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++.</div><div>3. A complete specification: see P0029. I do expect that specification to keep evolving, but not to become less complete.</div><div>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.</div><div>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.</div><div>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.</div><div><br></div><div>What are your thoughts? Also, who actually makes the decision on this?</div><div><br></div><div>[1] <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0029r0.html" target="_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0029r0.html</a></div><div>[2] <a href="http://clang.llvm.org/get_involved.html#criteria" target="_blank">http://clang.llvm.org/get_involved.html#criteria</a></div></div>
</blockquote></div><br></div>