Re: Quo Vadis tr1?

[Ville Voutilainen <ville dot voutilainen at gmail dot com>]

On 11 May 2018 at 15:31, Jonathan Wakely <jwakely@redhat.com> wrote:
>> 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 can't say I'm a fan of the third option from a library vendor's
work-load perspective, but I think
it's the right thing to do for users. Duplicate first, deprecate after
the duplicated implementation
has been out for some time, then remove if nobody complained about the
deprecation and
the removal before an actual release didn't break users (who may have
just silenced deprecation warnings as "shut
up, you're annoying me").