[libcxx-dev] [llvm-dev] Removing deprecated <ext/hash_set>, <ext/hash_map> and <ext/__hash>

[Chandler Carruth via libcxx-dev]

On Wed, Feb 6, 2019 at 10:23 AM Marshall Clow via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On Wed, Feb 6, 2019 at 9:36 AM Louis Dionne via libcxx-dev <
> libcxx-dev at lists.llvm.org> wrote:
>
>> On Feb 5, 2019, at 23:18, Chandler Carruth <chandlerc at gmail.com> wrote:
>>
>> 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. ;]
>>
>> 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?
>>
>>
>> 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.
>> hash_map probably has bugs that we haven't and won't fix, etc.
>>
>
> FWIW -- My response (for several years) to any reported problems in
> `__gnu_cxx::hash_map/set` has been "use the ones in std::, then"
>
> -- Marshall
>
> 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.
>

See my longer response to Louis for details, but FWIW, even this level of
"support" has been materially useful for our codebase. ::shrug::
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20190206/3db17806/attachment-0001.html>