Assignable<T&, T const&> unceremoniously blows up when T is vector<unique_ptr<int>>

[cjdb]

This might be a bug in GCC, not Ranges.

Link: https://godbolt.org/g/rxBUhq

#include <vector>
#include <memory>
#include <experimental/ranges/concepts>

using std::experimental::ranges::Assignable;
using T = std::vector<std::unique_ptr<int>>;
static_assert(Assignable<T&, T const&>);

int main()
{
    // diagnostic equivalent to:
    // T t1;
    // T t2;
    // t1 = t2;
}

[CaseyCarter]

Worse: it's a bug in the Standard. forward_list, list, and vector may each be instantiated with an incomplete element parameter T when the allocator parameter satisfies the allocator completeness requirements, provided that T is complete before referring to (instantiating) any member of the resulting specialization of forward_list/list/vector.

Among other possibilities, that wording seems to require:

struct TreeNode { std::vector<TreeNode> nodes; };

to be valid. There is no mechanism to constrain the special member functions of these containers that doesn't lead to constraint recursion for this recursive case: TreeNode is copyable iff std::vector<TreeNode> is copyable iff TreeNode is copyable.

(To be fair, my "bug in the standard" statement is hyperbole. The Standard does not require that the containers have constraints in place to ensure that one gets correct results upon applying type traits to containers. I think the Standard should do so, but we've painted ourselves into a corner with the allocator completeness requirements where it's impossible to do that.)