This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Add RequireInputIter on unordered containers
On 21/09/18 18:18 +0200, François Dumont wrote:
On 09/19/2018 11:01 AM, Jonathan Wakely wrote:
On 19/09/18 08:16 +0200, François Dumont wrote:
Unordered containers are missing the std::_RequireInputIter. Even
if deduction guides do have them.
Because that's what the standard requires, see [unord.req] p17.
17 A deduction guide for an unordered associative container shall
not participate in overload resolution if any of
the following are true:
— It has an InputIterator template parameter and a type that does
not qualify as an input iterator is
deduced for that parameter.
— It has an Allocator template parameter and a type that does not
qualify as an allocator is deduced
for that parameter.
— It has a Hash template parameter and an integral type or a type
that qualifies as an allocator is deduced
for that parameter.
— It has a Pred template parameter and a type that qualifies as an
allocator is deduced for that parameter.
There's no such constraint for the constructors.
It looks like we're not following the last two bullets though. We
don't constrain the Hash and Pred parameters.
Do you mean that we can't add them on unordered containers themselves ?
We *must* have those constraints on the deduction guides, because
they don't work otherwise (that's why the standard requires them).
We aren't required to put them on the constructors, and doing so is
observable (it changes the result of std::is_constructible for certain
arguments). It also means the compiler has to do more work during
overload resolution. So I'd prefer not to add those constraints, even
if we're allowed to (and I'm not sure we're allowed to, although it
wouldn't cause problems for any correct code).
At least on the insert method ? I faced an invalid call in my code and
generated error message was really awful.
A static_assert inside the constructor should improve the error
message, without affecting anything else.