[ConceptGCC]|
[ConceptGCC] |
ConceptGCC :Re: Shouldn't Assignable concepts stop supporting assignment-to-rvalue? |
From: Niels Dekker (nielsprogramming_at_[hidden])
Date: 2009-01-07 08:16:22
>> ... I'm working on a resolution of a library issue, proposing to
>> disallow assignment to an rvalue for most of the Standard Library
>> types: "Ref-qualifiers for assignment operators",
>> http://home.roadrunner.com/~hinnant/issue_review/lwg-active.html#941
Sebastian Gesemann wrote:
> I don't think that mistyping is a big issue. Adding ref qualifiers in
> the STL would take functionality away. So, it's not backwards
> compatible, strictly speaking.
Thanks for your feedback, Sebastian. Of course, I'd rather have you
support the idea of adding '&' ref-qualifiers to the assignment
operators provided by the STL (whenever appropriate). But anyway, it's
always good to hear a different opinion!
> I don't know whether this would really affect any code base, though.
I'm very interested to hear any use case of assignment to an rvalue. So
far, it only appears useful to me for very specific types, like proxy
classes. For example, bitset::reference and vector<bool>::reference.
slice_array, gslice_array, mask_array, and indirect_array have "const"
assignment operators, so I don't think those should have a ref-qualifier
either. I'm not entirely sure about the insert iterators
[insert.iterators], though. Do you think it makes sense to assign a
value of type Cont::value_type to a temporary
back_insert_iterator<Cont>?
> Anyhow, I'd like to see the ref qualifier in HasAssign<>:
>
> auto concept HasAssign<typename T, typename U>
> typename result_type;
> result_type T::operator=(U) &; // <-- added ref qualifier (not in
> // draft)
> }
>
> which would make the compiler reject your restricted function template
> "assign_to_rvalue".
Thanks! Would you also like to see the ref-qualifier in CopyAssignable
and MoveAssignable?
> The original version of this (N2800.pdf) obviously
> requires rvalues to be assignable as well which renders built-in types
> non-assignable as far as this concept is concerned.
Are you sure? When I try ConceptGCC 4.3.0 alpha 7, HasAssign<T,T>
(original version) appears to be satisfied when T is a built-in type:
////////////////////////////////////////////////////////////
#include <concepts>
template<typename T> requires std::HasAssign<T,T>
void assign_to_itself(T& arg)
{
arg = arg;
}
struct foo { int i; };
int main()
{
foo obj = { 42 };
assign_to_itself(obj); // accepted by ConceptGCC.
int i = 42;
assign_to_itself(i); // also accepted!
}
////////////////////////////////////////////////////////////
assign_to_itself(i) is accepted, even though HasAssign<T,T> seems to
require supporting assignment to an rvalue. Isn't that strange?
Kind regards, Niels