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

### 335. minor issue with char_traits, table 37

Section: 23.2.2 [char.traits.require] Status: CD1 Submitter: Andy Sawyer Opened: 2001-09-06 Last modified: 2016-01-28

Priority: Not Prioritized

View other active issues in [char.traits.require].

View all other issues in [char.traits.require].

View all issues with CD1 status.

Discussion:

Table 37, in 23.2.2 [char.traits.require], descibes char_traits::assign as:

      X::assign(c,d)   assigns c = d.

And para 1 says:

> [...] c and d denote values of type CharT [...]

Naturally, if c and d are values, then the assignment is (effectively) meaningless. It's clearly intended that (in the case of assign, at least), 'c' is intended to be a reference type.

I did a quick survey of the four implementations I happened to have lying around, and sure enough they all have signatures:

        assign( charT&, const charT& );

(or the equivalent). It's also described this way in Nico's book. (Not to mention the synopses of char_traits<char> in 21.1.3.1 and char_traits<wchar_t> in 21.1.3.2...)

Proposed resolution:

Add the following to 21.1.1 para 1:

> r denotes an lvalue of CharT

and change the description of assign in the table to:

      X::assign(r,d)   assigns r = d