Extending move semantics to *this (revised wording)

Bronek Kozicki and Daveed Vandevoorde

Purpose

This document is a revision of N1821 "Extending Move Semantics To *this (Revision 1)" . The aim of this paper is to fix flaws discovered in the formal wording proposed in N1821. This paper does not change semantics or syntax proposed in N1821. Instead, it merely strives to implement the intent of the original proposal.

Proposed wording (formal)

Following refers to the current draft N2315. Deletions are marked like this and additions are marked like this.

4 Declarators have the syntax

declarator:
    direct-declarator
    ptr-operator declarator

direct-declarator:
    declarator-id
    direct-declarator ( parameter-declaration-clause ) cv-qualifier-seqopt ref-qualifieropt exception-specificationopt
    direct-declarator [ constant-expressionopt ]
    ( declarator )

ptr-operator:
    *cv-qualifier-seqopt
    &
    &&
    ::opt nested-name-specifier * cv-qualifier-seqopt

cv-qualifier-seq:
    cv-qualifier cv-qualifier-seqopt

cv-qualifier:
    const
    volatile

ref-qualifier:
    &
    &&

...

1 To specify type conversions explicitly, and as an argument of sizeof, new, or typeid, the name of a type shall be specified. This can be done with a type-id, which is syntactically a declaration for an object or function of that type that omits the name of the object or function.

type-id:
    type-specifier-seq abstract-declaratoropt
    
type-specifier-seq:
    type-specifier type-specifier-seqopt

abstract-declarator:
    ptr-operator abstract-declaratoropt
    direct-abstract-declarator
    ...
direct-abstract-declarator:
    direct-abstract-declaratoropt
        ( parameter-declaration-clause ) cv-qualifier-seqopt ref-qualifieropt exception-specificationopt
    direct-abstract-declaratoropt [constant-expressionopt ]
    ( abstract-declarator )

It is possible to identify uniquely the location in the abstract-declarator where the identifier would appear if the construction were a declarator in a declaration. The named type is then the same as the type of the hypothetical identifier.

...

1 In a declaration T D where D has the form:

	D1 ( parameter-declaration-clause ) cv-qualifier-seqopt ref-qualifieropt exception-specificationopt

type of the contained declarator-id in the declaration T D1 is "derived-declarator-type-list T," the type of the declarator-id in D is "derived-declarator-type-list function of (parameter-declaration-clause) cv-qualifier-seq_opt ref-qualifier_opt returning T"; a type of this form is a function type ⁸⁵⁾.

...

4 A cv-qualifier-seq shall only be part of the function type for a non-static member function, the function type to which a pointer to member refers, or the top-level function type of a function typedef declaration. The effect of a cv-qualifier-seq in a function declarator is not the same as adding cv-qualification on top of the function type. In the latter case, the cv-qualifiers are ignored. [Example:

typedef void F();
struct S {
	const F f;              // OK: equivalent to: void f();
};

- end example] . A ref-qualifier shall only be part of the function type for a non-static member function, the function type to which a pointer to member refers, or the top-level function type of a function typedef declaration. The return type, the parameter type list, the ref-qualifier and the cv-qualifier-seq, but not the default arguments (8.3.6) or the exception specification (15.4), are part of the function type. [Note: function types are checked during the assignments and initializations of pointer-to-functions, reference-to-functions, and pointer-to-member-functions. - end note ]

2 The declarator in a function-definition shall have the form

	D1 ( parameter-declaration-clause ) cv-qualifier-seqopt ref-qualifieropt exception-specificationopt	

as described in 8.3.5. A function shall be defined only in namespace or class scope.

5 A cv-qualifier-seq Both a cv-qualifier-seq and a ref-qualifier can be part of a non-static member function declaration, non-static member function definition, or pointer to member function only (8.3.5); see 9.3.2. It is part of the function type.

5 A non-static member function may be declared with a ref-qualifier (8.3.5), see 13.3.1.

56 A non-static member function may be declared virtual (10.3) or pure virtual (10.4).

2 If a virtual member function vf is declared in a class Base and in a class Derived, derived directly or indirectly from Base, a member function vf with the same name, parameter-type-list (8.3.5), ref-qualifier (9.3.1) (or absence of same), and cv-qualification as Base::vf is declared, then Derive d::vf is also virtual (whether or not it is so declared) and it overrides⁹⁷⁾ Base::vf. For convenience we say that any virtual function overrides itself. Then in any well-formed class, for each virtual function declared in that class or any of its direct or indirect base classes there is a unique final overrider that overrides that function and every other overrider of that function. The rules for member lookup (10.2) are used to determine the final overrider for a virtual function in the scope of a derived class but ignoring names introduced by using-declaration s.

...

4 A constructor shall not be virtual (10.3) or static (9.4). A constructor can be invoked for a const, volatile or const volatile object. A constructor shall not be declared const, volatile, or const volatile (9.3.2). const and volatile semantics (7.1.5.1) are not applied on an object under construction. They come into effect when the constructor for the most derived object (1.8) ends. A constructor shall not be declared with a ref-qualifier (9.3.1).

2 A destructor is used to destroy objects of its class type. A destructor takes no parameters, and no return type can be specified for it (not even void). The address of a destructor shall not be taken. A destructor shall not be static. A destructor can be invoked for a const, volatile or const volatile object. A destructor shall not be declared const, volatile or const volatile (9.3.2). const and volatile semantics (7.1.5.1) are not applied on an object under destruction. They stop being in effect when the destructor for the most derived object (1.8) starts. A destructor shall not be declared with a ref-qualifier (9.3.1).

2 Certain function declarations cannot be overloaded:

• Function declarations that differ only in the return type cannot be overloaded.

• Member function declarations with the same name and the same parameter types cannot be overloaded if any of them is a static member function declaration (9.4). Likewise, member function template declarations with the same name, the same parameter-type-list, and the same template parameter lists cannot be overloaded if any of them is a static member function template declaration. The types of the implicit object parameters constructed for the member functions for the purpose of overload resolution (13.3.1) are not considered when comparing parameter-type-lists for enforcement of this rule. In contrast, if there is no static member function declaration among a set of member function declarations with the same name and the same parameter-type-list, then these member function declarations can be overloaded if they differ in the type of their implicit object parameter. [ Example: the following illustrates this distinction:

  class X {
      static void f();
      void f();                   //   ill-formed
      void f() const;             //   ill-formed
      void f() const volatile;    //   ill-formed
      void g();
      void g() const;             //  OK: no static g
      void g() const volatile;    //  OK: no static g
  };
  

  
  - end example]

• 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, and the same template parameter lists, cannot be overloaded if any of them, but not all, have a ref-qualifier (9.3.1). [ Example:

  class Y {
      void h() &;
      void h() const &; // OK
      void h() &&;      // OK, all declarations h() have a ref-qualifier  
      void i() &;
      void i() const;   // ill-formed, prior declaration i() has a ref-qualifier
  };
  

  - end example]

4 For non-static member functions, the type of the implicit object parameter is "reference to cv X"

• "lvalue-reference to cv X" for functions declared without a ref-qualifier (9.3.1) or with the & ref-qualifier
• "rvalue-reference to cv X" for functions declared with the && ref-qualifier

where X is the class of which the function is a member and cv is the cv-qualification on the member function declaration. [Example: for a const member function of class X, the extra parameter is assumed to have type "reference to const X". - end example ] For conversion functions, the function is considered to be a member of the class of the implicit object argument for the purpose of defining the type of the implicit object parameter. For non-conversion functions introduced by a using-declaration into a derived class, the function is considered to be a member of the derived class for the purpose of defining the type of the implicit object parameter. For static member functions, the implicit object parameter is considered to match any object (since if the function is selected, the object is discarded). [Note: no actual type is established for the implicit object parameter of a static member function, and no attempt will be made to determine a conversion sequence for that parameter (13.3.3). - end note]

5 During overload resolution, the implied object argument is indistinguishable from other arguments. The implicit object parameter, however, retains its identity since conversions on the corresponding argument shall obey these additional rules:

• no temporary object can be introduced to hold the argument for the implicit object parameter; and

• no user-defined conversions can be applied to achieve a type match with it; and

For non-static member functions declared without a ref-qualifier (9.3.1), an additional rule applies:

• even if the implicit object parameter is not const-qualified, an rvalue temporary can be bound to the parameter as long as in all other respects the temporary can be converted to the type of the implicit object parameter. [ Note: The fact that such a temporary is an rvalue does not affect the ranking of implicit conversion sequences (13.3.3.2). - end note ]

3 Two implicit conversion sequences of the same form are indistinguishable conversion sequences unless one of the following rules apply:

• S1 and S2 differ only in their qualification conversion and yield similar types T1 and T2 (4.4), respectively, and the cv-qualification signature of type T1 is a proper subset of the cv-qualification signature of type T2, and S1 is not the deprecated string literal array-to-pointer conversion (4.2). [Example:

  int f(const int *);
  int f(int *);
  int i;
  int j = f(&i);                       //  calls  f(int *)
  

  --- end example] or, if not that,
• S1 and S2 are reference bindings (8.5.3) and neither refers to an implicit object parameter of a non-static member function declared without a ref-qualifier (9.3.1), and either S1 binds an lvalue reference to an lvalue and S2 binds an rvalue reference or S1 binds an rvalue reference to an rvalue and S2 binds an lvalue reference.

Acknowledgments

I wish to thank Jens Maurer for much needed reviews and corrections and Howard Hinnant for valuable input. Special thanks goes to my wife Malgosia for allowing me to work on this document.