Are you sure? Doesn't it refer to the assignment expression as a whole? The expression f() = 5 has value 5, and that value replaces the value of the left operand.

The assignment expression as a whole is an lvalue referring to the left operand.

This sounds like a core issue. How does one turn an edit issue into a core issue?

@burblebee: I think you wait until a friendly person (hello @zygoloid) emails the issue to the Core chair... :-)

We had a couple of instances already where the introduction of brace-init-lists in various contexts technically invalidated descriptions talking about "expressions". It seems very obvious what is meant here (= "right operand"), so I believe this could be handled editorially.

For @zygoloid to decide, of course.

The current proposed solution doesn't work, because a braced-init-list does not have a value. So the description needs to distinguish between operands that have a value, and those that are described by p9.

From a discussion with @zygoloid:

1. change p2 to say

In a simple assignment (=) whose right operand is an assignment-expression, the value of the that expression [...]"

2. then p9 would define what happens in the other case in terms of the p2 or p4 wording
3. maybe moving the assignment-expression / braced-init-list dispatch up front might be cleaner
4. also, talking about what happens for class types here is unnecessary; none of the other overloadable operators bother with that, and the [expr] frontmatter covers it already.

Posted to the core reflector so that we get a core issue: http://lists.isocpp.org/core/2016/12/1382.php

See also CWG 1542.

Handled by CWG 2399.

Fixed by 9700b13 (Nov 2019).