Re: [boost] [type_traits] has_equal_to< std::vector<T> > alwaystrue_

Subject: Re: [boost] [type_traits] has_equal_to< std::vector<T> > alwaystrue_
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2011-10-22 06:18:00

Le 22/10/11 10:25, John Maddock a écrit :
>> Thanks for highlighting this major issue. I understand that there is
>> nothing to do apart from specializing the traits for those particular
>> std classes. This would however not work with user classes. As the
>> beta is due on Monday, I believe it is too short to submit a working
>> and tested patch. Maybe once the beta is out, you can start to work on
>> a proposed contribution?
>> Meanwhile, as suggested I will add a warning in the doc.
>
> It's a tricky one, because strictly speaking vector<T> always does 
> have an equality operator - it's just that depending upon T it may not 
> compile :-(
>
> There's no general solution to this, because there's no way in the 
> language to test whether something does or does not compile - we can 
> only test whether it's declared or not.
>
Hi,

I'm not sure  I understand the standard correctly. The standard says 
container requirements "Requires: T is EqualityComparable".

Does this means that the operator== must not participate in overload 
resolution when the requirements are not meet, or that the compilation 
will fail?
IMO, it is the first. In other parts of the standard the wording is more 
explicit. For example in the chrono part, every function that has some 
constraints in the template types, state something like:

"Remarks: This operator shall not participate in overload resolution 
unless Rep2 is implicitly convertible to CR(Rep1, Rep2)."

The same kind of wording is found for std::pair:

"
template<class U, class V> pair(const pair<U, V>& p);
Requires: is_constructible<first_type, const U&>::value is true and 
is_constructible<second_- type, const V&>::value is true.
Effects: Initializes members from the corresponding members of the 
argument.
Remark: This constructor shall not participate in overload resolution 
unless const U& is implicitly convertible to first_type and const V& is 
implicitly convertible to second_type.
"

I don't know if the standard is not enough precise respect to the 
operator== for container, but this merits clarification anyway.

Best,
Vicente