llvm dev - Feb 2019 - Removing deprecated <ext/hash_set>, <ext/hash_map> and <ext/__hash>

Hi,

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: https://reviews.llvm.org/D57688 <https://reviews.llvm.org/D57688>.

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.

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.

Thanks!
Louis

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190204/f75cac1f/attachment.html>

Well, it would be interesting to do a FreeBSD ports exp-run with these headers
removed.  You'd be surprised how much software is out there using obsolete,
experimental and/or not even officially existing headers. :-)

-Dimitry
> On 4 Feb 2019, at 20:31, Louis Dionne via libcxx-dev <libcxx-dev at
lists.llvm.org> wrote:
> 
> Hi,
> 
> 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: https://reviews.llvm.org/D57688 <https://reviews.llvm.org/D57688>.
> 
> 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.
> 
> 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.
> 
> Thanks!
> Louis
> 
> _______________________________________________
> libcxx-dev mailing list
> libcxx-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190205/e2a83ea3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 223 bytes
Desc: Message signed with OpenPGP
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190205/e2a83ea3/attachment.sig>

> On Feb 5, 2019, at 01:53, Dimitry Andric <dimitry at andric.com>
wrote:
> 
> Well, it would be interesting to do a FreeBSD ports exp-run with these
headers removed.  You'd be surprised how much software is out there using
obsolete, experimental and/or not even officially existing headers. :-)
Please do so and report on the results. One solution might be to ship those
headers outside of libc++ for projects that still need them.

Louis
> 
> -Dimitry
> 
>> On 4 Feb 2019, at 20:31, Louis Dionne via libcxx-dev <libcxx-dev at
lists.llvm.org <mailto:libcxx-dev at lists.llvm.org>> wrote:
>> 
>> Hi,
>> 
>> 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: https://reviews.llvm.org/D57688 <https://reviews.llvm.org/D57688>.
>> 
>> 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.
>> 
>> 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.
>> 
>> Thanks!
>> Louis
>> 
>> _______________________________________________
>> libcxx-dev mailing list
>> libcxx-dev at lists.llvm.org <mailto:libcxx-dev at
lists.llvm.org>
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190205/695de81c/attachment-0001.html>

On Mon, Feb 04, 2019 at 02:31:54PM -0500, Louis Dionne via llvm-dev
wrote:
> 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: https://reviews.llvm.org/D57688
<https://reviews.llvm.org/D57688>.
You haven't said anything about *why* they should be removed. Seriously,
removal just creates a maintainance burden for little to no reason. As
with many other such proposals: the burden is not on your shoulder, but
on maintainers of build systems like pkgsrc, ports or the like. It's
nice that things get deprecated. But changing existing software is a lot
of effort, esp. when it is no longer actively maintained.

Joerg

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?

-Chandler

On Mon, Feb 4, 2019 at 11:32 AM Louis Dionne via libcxx-dev <
libcxx-dev at lists.llvm.org> wrote:
> Hi,
>
> 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: https://reviews.llvm.org/D57688.
>
> 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.
>
> 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.
>
> Thanks!
> Louis
>
> _______________________________________________
> libcxx-dev mailing list
> libcxx-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190205/326cf65b/attachment.html>

> 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.

Libc++ implements a Standard. __gnu_cxx::hash_map 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.

What I'm trying to do here is understand whether and why __gnu_cxx::hash_map
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.

Louis
> 
> -Chandler
> 
> On Mon, Feb 4, 2019 at 11:32 AM Louis Dionne via libcxx-dev <libcxx-dev
at lists.llvm.org <mailto:libcxx-dev at lists.llvm.org>> wrote:
> Hi,
> 
> 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: https://reviews.llvm.org/D57688 <https://reviews.llvm.org/D57688>.
> 
> 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.
> 
> 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.
> 
> Thanks!
> Louis
> 
> _______________________________________________
> libcxx-dev mailing list
> libcxx-dev at lists.llvm.org <mailto:libcxx-dev at lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev
<https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190206/961626ca/attachment-0001.html>