<div dir="ltr"><div dir="ltr"><div dir="ltr">On Wed, Feb 6, 2019 at 9:36 AM Louis Dionne via libcxx-dev <<a href="mailto:libcxx-dev@lists.llvm.org">libcxx-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><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;"><div><blockquote type="cite"><div>On Feb 5, 2019, at 23:18, Chandler Carruth <<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>> wrote:</div><br class="gmail-m_3134148053868659525Apple-interchange-newline"><div><div dir="ltr"><div dir="ltr">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"><br></div><div>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></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">hash_map</font> probably has bugs that we haven't and won't fix, etc.</div></div></div></blockquote><div><br></div><div>FWIW -- My response (for several years) to any reported problems in `__gnu_cxx::hash_map/set` has been "use the ones in std::, then"</div><div><br></div><div>-- Marshall</div><div><br></div><div>P.S. The implementation in __gnu_cxx is NOT a faithful implementation of what libstdc++ has; it is a wrapper over std::unordered_map/set.</div><div><br></div></div></div></div>