This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD status.

### 2580. Who is definitive: `operator=` or `assign`?

Section: 23.4.3.3 [string.cons], 23.4.3.7.3 [string.assign], 32.7.3 [re.regex.assign] Status: NAD Submitter: Marshall Clow Opened: 2016-01-05 Last modified: 2016-11-12

Priority: 4

View all other issues in [string.cons].

View all issues with NAD status.

Discussion:

There are two "containers" in the standard who have member functions named `assign` that take parameters of the type of the container (as opposed to iterators, pointers, what have you).

In `string`'s case, we define `assign` in terms of `operator=`. In `regex`'s case, we define `operator=` in terms of `assign`.

We should pick a style and use use it.

In 23.4.3.3 [string.cons], we have:

>     basic_string& operator=(const basic_string& str);

> > -17- Effects: If `*this` and `str` are not the same object, modifies `*this` as shown in Table 70.

> > -18- If `*this` and `str` are the same object, the member has no effect.

> > -19- Returns: `*this`

>     basic_string& operator=(basic_string&& str)
>       noexcept(allocator_traits<Allocator>::propagate_on_container_move_assignment::value ||
>                allocator_traits<Allocator>::is_always_equal::value);

> > -20- Effects: Move assigns as a sequence container (23.2), except that iterators, pointers and references may be invalidated.

> > -21- Returns: `*this`

In 23.4.3.7.3 [string.assign], we have:

>     basic_string& assign(const basic_string& str);

> > -1- Effects: Equivalent to `assign(str, 0, npos)`.

> > -2- Returns: `*this`.

>     basic_string& assign(basic_string&& str)
>       noexcept(allocator_traits<Allocator>::propagate_on_container_move_assignment::value ||
>                allocator_traits<Allocator>::is_always_equal::value);

> > -2- Effects: Equivalent to `*this = std::move(str)`.

> > -3- Returns: `*this`.

Marshall says: There is another issue 2579 here, to change /1 to be similar to /2.

In 32.7.3 [re.regex.assign], we have:

>     basic_regex& operator=(const basic_regex& e);

> > -1- Effects: returns `assign(e)`.

>     basic_regex& operator=(basic_regex&& e) noexcept;

> > -2- Effects: returns `assign(std::move(e))`.

and

>     basic_regex& assign(const basic_regex& that);

> > -7- Effects: copies `that` into `*this` and returns `*this`.

> > -8- Postconditions: `flags()` and `mark_count()` return `that.flags()` and `that.mark_count()`, respectively.

>     basic_regex& assign(basic_regex&& that) noexcept;

> > -9- Effects: move assigns from `that` into `*this` and returns `*this`.

> > -10- Postconditions: `flags()` and `mark_count()` return the values that `that.flags()` and `that.mark_count()`, respectively, had before assignment. `that` is in a valid state with unspecified value.

[2016-02, Issues Telecon]

Marshall to see if this can be dealt with editorially. Change Regex so that assign is in terms of op=

[2016-02]

Changed `basic_regex` to match `string` as an editorial change. Closing as NAD

Proposed resolution: