[PATCH] PR77990 refactor unique_ptr to encapsulate tuple

[Jonathan Wakely]

On 17/10/16 14:37 +0100, Jonathan Wakely wrote:
>We are incorrectly requiring unique_ptr deleters to be copyable here:
>
>     explicit
>     unique_ptr(pointer __p) noexcept
>     : _M_t(__p, deleter_type())
>     { }
>
>We could just do:
>
>     explicit
>     unique_ptr(pointer __p) noexcept
>     : _M_t()
>     { std::get<0>(_M_t) = __p; }
>
>But having to deal directly with the std::tuple inside unique_ptr has
>been bothering me for some time. The tuple is used so we get the empty
>base-class optimisation for the deleter, but that implementation
>detail

ops, a dangling sentence. I meant to say that the tuple implementation
details leaks into the definition of lots of members, which have to
say std::get<0>(_M_t) or std::get<1>(_M_t) instead of using more
natural member names.

>This patch refactors unique_ptr to put the std::tuple member into a
>new type which provides named accessors for the tuple elements, so we
>can stop using get<0> and get<1>. That new type can also provide a
>single-argument constructor to fix the copyable requirement for
>deleters. This also removes the code for deducing the pointer type
>which is duplciated in unique_ptr and unique_ptr<T[], D>, and while in
>the neighbourhood I changed it from old-school SFINAE using overloaded
>functions to the new hotness with __void_t<>.
>
>I intend to commit this to trunk, but on the branches I'll just fix
>the constructor as shown above, as it's a smaller change.

I'll wait a bit longer for any objections, as the refactoring could be
seen as unnecessary churn, but I think it's valuable housekeeping.