
<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Feb 5, 2019, at 23:18, Chandler Carruth <<a href="mailto:chandlerc@gmail.com" class="">chandlerc@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class="">FWIW, I'm pretty sure we still have plenty of code using them. We've not done any analysis to see what timeframe that code could be be updated on -- our focus has been on *adopting* libc++ (and easing that path), not removing the uses of weird things that it also supports. I'll point out that I'd rather focus our energy on adopting libc++ than even doing this analysis. ;]</div><div dir="ltr" class=""><br class=""></div><div class="">I somewhat agree with Joerg that it would be good to understand the motivation. Much like a bunch of our other compatibility things (GCC flags, language extensions, etc.), having these headers helps encourage / ease adoption which seems a generally good thing for libc++. I can imagine that there is some large cost to keeping these around that would motivate removing them, but I don't see anything about that in the above?</div></div></div></blockquote><div><br class=""></div><div>To be clear: there is not a large cost in keeping those headers around. I don't think that's the question, since the same could be said of almost any removal of deprecated API. The cost of keeping code around is usually not that large if you decide not to maintain it anymore. But that's called code rot, and it's generally not a good idea to accumulate too much of it. <font face="Monaco" class="">hash_map</font> probably has bugs that we haven't and won't fix, etc.</div><div><br class=""></div><div>Libc++ implements a Standard. <font face="Monaco" class="">__gnu_cxx::hash_map</font> is not part of (any version of) that Standard, and so it does not belong in libc++. When I remove or rename some internal function inside libc++ that uses reserved identifiers, I don't bother asking on this list. It doesn't mean that I purposefully try to break users (quite the opposite), but I know where the line is drawn when/if users break because they use implementation details. This is also very similar to how we deprecate AND remove TSes one year after they are merged into the Standard. The amount of breakage caused by removing `<experimental/optional>` was non-trivial in our case, but we dealt with it and now our code is better.</div><div><br class=""></div><div>What I'm trying to do here is understand whether and why <font face="Monaco" class="">__gnu_cxx::hash_map</font> is special in that respect. Why was it put there in the first place? Why is it so hard to get rid of? If somebody can explain why it should be kept around, I'm happy to talk about it (this is why we have this thread). However, the argument of "we're too busy/lazy to update our code" doesn't sound like a very strong one to me, especially coming from someone that has excellent tools to deal with this kind of problem. So there must be something else underneath, and that's what I would love to understand.</div><div><br class=""></div><div>Louis</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">-Chandler</div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 4, 2019 at 11:32 AM Louis Dionne via libcxx-dev <<a href="mailto:libcxx-dev@lists.llvm.org" class="">libcxx-dev@lists.llvm.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;" class="">Hi,<div class=""><br class=""></div><div class="">Libc++ has been shipping the <ext/hash_set>, <ext/hash_map> and <ext/__hash> headers for a while and they are deprecated. Those headers contain data structures like __gnu_cxx::hash_map that have replacements like std::unordered_map. I would like to remove those headers. I've put up a patch for review but I won't commit it until we have a sort of plan because I know some people have expressed feelings about removing the headers in the past: <a href="https://reviews.llvm.org/D57688" target="_blank" class="">https://reviews.llvm.org/D57688</a>.</div><div class=""><br class=""></div><div class="">FWIW, I've compiled a large code base with that patch and I didn't get any trouble. I suspect the amount of breakage this will cause is manageable especially if we give advance notice, but others might disagree.</div><div class=""><br class=""></div><div class="">Is anybody opposed to removing those headers? If you're opposed to the removal, please explain why and what removal timeline/plan would work for you.</div><div class=""><br class=""></div><div class="">Thanks!</div><div class="">Louis</div><div class=""><br class=""></div></div>_______________________________________________<br class="">

libcxx-dev mailing list<br class="">

<a href="mailto:libcxx-dev@lists.llvm.org" target="_blank" class="">libcxx-dev@lists.llvm.org</a><br class="">

<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev" rel="noreferrer" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev</a><br class="">

</blockquote></div></div>

</div></blockquote></div><br class=""></body></html>