On 17 August 2018 at 22:29, Jonathan Wakely <jwak...@redhat.com> wrote: > That was added by https://gcc.gnu.org/ml/libstdc++/2016-12/msg00122.html > but I see no justification for that in the standard (and neither > libc++ nor MSFTL does anything special here, so they fail the test > too). > > Ville, I'm no longer convinced by your rationale. Why is that
You mean the part where I said "the variadic constructor doesn't run into this problem"? I may have been wrong about the variadic. > constraint on the 2-tuple partial specialization when the standard > doesn't say anything like "if sizeof...(Types)==2 this constructor > shall not participate in overload resolution unless decay_t<U_i> is > not allocator_arg_t" for the tuple(_UTypes&&...) constructor? > > As far as I can tell, the standard says that the test is wrong. > > If we think the test is right, we should report a defect. Either way, > I think this patch would be a nice simplification. We can either fix > (or just remove) the test, or constrain the primary template. I think the test is reasonable to the point of being obvious. If you pass an allocator_arg and an allocator, the intent is that uses-allocator construction is always used, not that it's used unless the element type is constructible from allocator_arg and an allocator. While the explicitness and presence of some tuple constructors depends on the properties of the element types, the semantics of the allocator constructors should not depend on them to decide whether to do uses-allocator construction or not - that would be a vector<bool> again.
