Do std::tuple and std::pair support aggregate initialization?

Question

Aggregate initialization requires among other things no user-provided constructors. But std::tuple and std::pair pair have a large set of overloaded constructors. From the point of the core language, are these constructors user-provided or even user-declared ?

With C++17 it will be possible to write (update/clarification: where nocopy is a class that can not be copied or moved, such as std::mutex)

auto get_ensured_rvo_str(){
   return std::pair(std::string(),nocopy());
}

edit: no, it's not possible as explained in the linked to answers and the answer below.

which requires aggregate initialization (for context: Multiple return values (structured bindings) with unmovable types and guaranteed RVO in C++17).

Are tuple and pair backed by special standard language to allow this (in presence of constructors) ? :

20.5.2.1 Construction

... EXPLICIT constexpr tuple(const Types&...);

6 Effects: The constructor initializes each element with the value of the corresponding parameter.

or can we in principle write our own tuple or pair?

Answer 1

No, there is no support in tuple or pair for passing no-move types to their constructors, and as you've observed there cannot be, since the constructor argument and tuple (or pair) member can be observed to be different objects:

// exposition only
template<class... Us>
tuple(Us&&... us) : values{std::forward<Us>(us)...} {}
              ^^ these
                    ^^^^^^ are different objects to these

You would have to use piecewise construction:

return std::pair<std::string, nocopy>(std::piecewise_construct,
    std::forward_as_tuple(), std::forward_as_tuple());

Matt Calabrese made an interesting point on the std-proposals list that now we have guaranteed RVO it should be possible to write components that accept factories to construct their members effectively inplace:

// hypothetical factory constructor
return std::pair(std::factory_construct,
    [] { return std::string{}; }, [] { return nocopy{}; });

Another possible direction would be to remove the constructors from tuple and pair (or, more realistically, to write workalike components without constructors) and rely on the new extensions to aggregate initialization that should permit aggregate initialization of tuple and pair implemented via multiple-inheritance. Example.