[ConceptGCC]|
[ConceptGCC] |
ConceptGCC :[SPAM:### 82%] Re: Shouldn't Assignable concepts stop supporting assignment-to-rvalue? |
From: Niels Dekker (nielsprogramming_at_[hidden])
Date: 2009-01-07 15:10:07
>> Do you think it makes sense to assign a value of type
>> Cont::value_type to a temporary back_insert_iterator<Cont>?
Sebastian Gesemann wrote:
> You wouldn't usually try to assign an object of type Cont::value_type
> to an iterator without dereferencing it first. According to 24.4.2.1
> [back.insert.iterator, N2800.pdf] the dereference operator returns an
> lvalue reference (to the iterator itself but that's not important).
> So, we're fine.
Thanks, I'll make sure that the proposed resolution of LWG 941,
"Ref-qualifiers for assignment operators"
(http://home.roadrunner.com/~hinnant/issue_review/lwg-active.html#941)
will include ref-qualifiers for insert iterators.
>> Would you also like to see the ref-qualifier in
>> CopyAssignable and MoveAssignable?
>
> CopyAssignable<T> and MoveAssignable<T> are refinements of
> HasAssign<T,const T&> and HasAssign<T, T&&>. So, there would be no
> need to change the other concepts as well.
Aah, of course! And TriviallyCopyAssignable<T> is a refinement of
CopyAssignable<T>, so TriviallyCopyAssignable wouldn't need to be
changed either.
> [...] But an associated member function requirement
> without any ref qualifier only means that the member function can be
> invoked on lvalues. So, in case I got that right the following should
> be true:
>
> concept Test1<typename T> {
> void T::foo(); // requirement for lvalues only
> }
>
> concept Test2<typename T> {
> void T::foo(); // requirement for lvalues only
> void T::foo() &&; // requirement for rvalues only
> }
I'm not sure if Test2 is okay. Because there's this rule that if one
overload has a ref-qualifier, all overload should have them: "Member
function declarations with the same name and the same
parameter-type-list as well as member function template declarations
with the same name, the same parameter-type-list, the same template
parameter lists, and the same template requirements cannot be overloaded
if any of them, but not all, have a ref-qualifier (8.3.5)."
[over.load]/2. Don't you think this applies to concepts as well?
> struct A {
> void foo() &; // <- note ref qualifier
> };
>
> struct B {
> void foo();
> };
>
> concept_map Test1<A> {} // OK
> concept_map Test2<A> {} // Error
> concept_map Test1<B> {} // OK
> concept_map Test2<B> {} // OK
>
>
> It certainly is a slight inconsistency since the meaning of the lack
> of a ref qualifier depends on the context (function requirement versus
> declaration).
>
> My personal conclusion: The current standard draft is fine w.r.t. the
> HasAssign<> and XxxAssignable<> concepts. Your ConceptGCC version is
> buggy because these concepts don't support assignment to rvalues and
> yet your constrained tempalte made use of it. ConceptGCC should have
> rejected your constrained template "assign_to_rvalue". But the
> inconsistency is bugging me. I see no problem in changing the
> "satisfaction rules" for member function requirements so that the lack
> of a ref qualifier should make the requirement satisfied only if BOTH
> versions of the expression E ('x' being an lvalue in one case and an
> rvalue in the other case) are well-formed. This modification would
> necessitate the addition of an lvalue ref qualifier in function
> requirements to keep the same semantics.
Thanks! I just saw your comp.std.c++ posting, "C++0x concepts and ref
qualifiers inconsistency",
http://groups.google.com/group/comp.std.c++/browse_frm/thread/6f3b093d7083ac18
I hope there will be some feedback, clarifying the issue...
Kind regards, Niels