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.
