<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 6, 2019 at 10:23 AM Marshall Clow via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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" target="_blank">libcxx-dev@lists.llvm.org</a>> wrote:<br></div></div></div><div dir="ltr"><div dir="ltr"><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><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="m_-2830512773224536662gmail-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></div></div><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><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></div></div><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>-- Marshall</div></div></div></div><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><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></div></div></blockquote><div><br></div><div>See my longer response to Louis for details, but FWIW, even this level of "support" has been materially useful for our codebase. ::shrug::</div></div></div>