Re: Quo Vadis tr1?

[Jonathan Wakely <jwakely at redhat dot com>]

On 10/05/18 22:03 -0400, Ed Smith-Rowland wrote:
> All,
>
> Apologies to whoever got this before, I meant to sent to libstdc++.
> From discussion of maths special functions issue PR83140;
>
> > We could consider dropping the TR1 support, and just provide these
> > functions for ISO/IEC 29124:2010 in C++11 (or later) and for C++17.
> > But that decision should be taken separately, and should only happen
> > on trunk anyway so we need to use _Tp(+1) here.
>
> I am in favour of splitting new versions of the special functions out of tr1 and into std/bits.
> I personally am itching to use at least C++11 for implementation.
> We have been defaulting to C++11 for, IIRC, two releases (Hence my -Tp{+1} slip).

Yes, the default has been -std=gnu++14 since GCC 6.1 two years ago.
All currently supported releases default to C++14.

> I have a lot of work towards this that I wanted to get into 9 anyway.
>
> This would end the last useful thing in tr1 that's not better implemented elsewhere.
> There are certainly people using tr1. Can we deprecate the whole namespace?
> That might be too noisy.

We could just document that it's deprecated and not actually add
__attribute__((__deprecated__)) to anything. I think it's probably
better to add the attribute though.

We have a few choices:

- deprecated *everything* from TR1.
- deprecate the TR1 versions of the special functions.
- duplicate the implementations of the special functions and leave the
 TR1 versions to bitrot and start using C++11 in the new copies of
 the code. (And optionally also deprecate some or all of TR1).

The first option is pretty aggressive and would definitely affect some
packages shipped by GNU/Linux distros today. I routinely come across
packages that still use TR1 stuff when I'm rebuilding/porting/fixing
packages in Fedora.

The third option is basically what we've done for shared_ptr,
function, bind, unordered_map etc. that originally came from TR1.
They're not deprecated, but they're barely maintained (which is OK as
they don't take much effort these days).

I think duplicating it means a lot more code in our repo, but is the
only way to start using C++11 *today*, rather than in two or more
years when (or if!) we actually remove the deprecated TR1 stuff. We
probably won't need to do much maintenance to the TR1 versions, any
as-yet-undiscovered bugs can stay there and just get fixed in the new
copy of the code.

> I think we should be done with the special maths bugs in Bugzilla pretty soon.

Nice.

> Ed
>
> Also, I think 83566 should go into tr1 first because it's not a
> signature change.

Agreed.