<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 6, 2019 at 9:36 AM Louis Dionne 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 style="word-wrap:break-word;line-break:after-white-space"><div><br><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_6682499914663859043Apple-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></div><div style="word-wrap:break-word;line-break:after-white-space"><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><br></div><div>Libc++ implements a Standard. <font face="Monaco">__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></div></blockquote><div><br></div><div>FWIW, I think extensions for compatibility are interestingly different from TSes. Clang also implements standards but supports a wide range of extensions for compatibility with both GCC and MSVC. Unlike TSes and other things with a clear path forward, many of these extensions don't have that clear path forward. I'm not trying to say __gnu_cxx::hash_map is *necessarily* the same, just that I think there is likely to be different needs for compatibility extensions than for "early versions" of standards-tracked things.</div><div><br></div><div>And of course, any such way of handling needs to have a reasonable benefit given the cost, and have a reasonable plan in place for maintaining it and supporting it without holding back the larger project.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><div><br></div><div>What I'm trying to do here is understand whether and why <font face="Monaco">__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?</div></div></div></blockquote><div><br></div><div>Sure, I'm happy to provide some of the historical context (I think I was one of the people arguing it should be added).</div><div><br></div><div>When we first tried even minor adoption of libc++ we couldn't make it far in even small scale experiments because so much of our code relied on __gnu_cxx::hash_map. This was a lot of years ago, and we had no realistic way to migrate things, much less to do so when we hadn't even conducted the experiment to see what moving to libc++ would look like.</div><div><br></div><div>At the time, I argued that this would likely be reasonably common for code building against libstdc++ for many years, much like reliance on GNU extensions to C and C++ is widespread. To make adoption effective, some of these need to be supported even if we would prefer people converge on the standard facilities. Things like `__thread` come to mind.</div><div><br></div><div>Some of this code isn't even being updated to C++11 actively. While it builds with C++11, this is largely because C++11 didn't break anything it relied on. I think it is important that Clang and libc++ both support such code to some extent in order to maximize their adoption in the larger Linux ecosystem (and likely BSD, but I know less there). That support doesn't have to be perfect of course, and the engineering costs should be considered for anything like this. But even the imperfect __gnu_cxx::hash_* stuff libc++ provides has empirically had value for at least a few code bases trying to adopt libc++. So I don't think the tradeoff is trivial here.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><div> If somebody can explain why it should be kept around, I'm happy to talk about it (this is why we have this thread).</div></div></div></blockquote><div><br></div><div>I think the argument when it was added still holds: there is likely to be a great deal of code written against this because for many years it was the only viable option, and it has been stable and reliably available in libstdc++. I think making it easy for existing codebases to move to libc++ is good for the project, the same way that I think making it easy to move to Clang is good for that project.</div><div><br></div><div>I can make a somewhat stronger argument that Google specifically would need this to remain to continue working on adoption. We will likely be able to eventually move off of this, but our priority at the moment is getting *on* to libc++, and there are already enough barriers there that I would very much like to avoid adding another component to that.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><div> 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.</div></div></div></blockquote><div><br></div><div>Let's avoid terms like "lazy". =]</div><div><br></div><div>I don't think what I said was that we were busy? Sorry if it came across that way. I've tried to expand on it a bit above.</div><div><br></div><div>But my second point was not about specific needs of existing users. Instead, it was about users we *don't yet have*. I think there may be significant value to them of supporting some extensions like this, and hopefully above I've given more useful details about this value. Let me know if this is the kind of information you're looking for.</div></div></div>