Proposed resolution:

In the class definition of basic_regex, just below [re.regex]/3, perform the following changes:

1. Just after basic_regex(const basic_regex&); insert:

   basic_regex(basic_regex&&);
   

2. Just after basic_regex& operator=(const basic_regex&); insert:

   basic_regex& operator=(basic_regex&&);
   

3. Just after basic_regex& assign(const basic_regex& that); insert:

   basic_regex& assign(basic_regex&& that);
   

4. In [re.regex.construct], just after p.11 add the following new member definition:

   basic_regex(basic_regex&& e);
   

   Effects: Move-constructs a basic_regex instance from e.

   Postconditions: flags() and mark_count() return e.flags() and e.mark_count(), respectively, that e had before construction, leaving e in a valid state with an unspecified value.

   Throws: nothing.

5. Also in [re.regex.construct], just after p.18 add the following new member definition:

   basic_regex& operator=(basic_regex&& e);
   

   Effects: Returns the result of assign(std::move(e)).

6. In [re.regex.assign], just after p. 2 add the following new member definition:

   basic_regex& assign(basic_regex&& rhs);
   

   Effects: Move-assigns a basic_regex instance from rhs and returns *this.

   Postconditions: flags() and mark_count() return rhs.flags() and rhs.mark_count(), respectively, that rhs had before assignment, leaving rhs in a valid state with an unspecified value.

   Throws: nothing.

[ 2009-07 Frankfurt: ]

Move to Ready.

[ Post Summit Daniel updated wording to reflect new "swap rules". ]

[ Sophia Antipolis: ]

Needs wording for the semantics, the idea is agreed upon.

Addresses UK 316

According to the current state of the standard draft, the class template basic_regex, as described in [re.regex]/3, is neither MoveConstructible nor MoveAssignable. IMO it should be, because typical regex state machines tend to have a rather large data quantum and I have seen several use cases, where a factory function returns regex values, which would take advantage of moveabilities.