[patch] Constrain allocator_arg_t to only work with valid Allocators

[Jonathan Wakely]

This is what I have been experimenting with as an alternative to
making allocator_arg_t non-DefaultConstructible.

By replacing allocator_arg_t parameters with __alloc_arg_t<_Alloc> we
can constrain constructors to only participate in overload resolution
when _Alloc quacks sufficiently like an allocator.

This ensures that tuple<T,U>{ {} , U{} } is unambiguous (unless U
happens to be an allocator, or a reasonable forgery of one).

Making this change required fixing some tests where I was passing
fake allocator arguments to tuples, which violated the preconditions
before but was accepted. Rejecting those precondition violations at
compile-time suggests to me that this is a nice improvement. The
downside is that it probably hurts compilation times even more, as
every change related to allocators seems to.

Any comments or suggestions about this approach?

I'm also playing with another change to make allocator_traits<A>
SFINAE-friendly, by only defining the nested allocator_type member
when __is_allocator<A> is true. If it works I think that might be
worth standardising.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.txt
Type: text/x-patch
Size: 15574 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20150630/137ccc57/attachment.bin>