CWG in Tokyo 2024-03-22

Different approaches are feasible:

• Require merging of string literals (and backing arrays of character types?) at compile-time: Comparing addresses of string literals is equivalent to comparing their contents.
• Being able to guarantee that addresses of string literals with different contents are unequal also at compile time seems useful. In particular, this idea would allow comparisons during constant evaluation if (and only if) the runtime result is reliable.
• At compile time, tag each evaluation of a string literal with a globally-unique counter value. Comparing two such pointers with different tags makes the evaluation not a constant expressions.
• At compile time, each string literal (as written in the source code) yields a different address. Repeated evaluations of the same string literal yield pointers that compare equal. This can be achieved by tagging the pointer to the string literal obtained upon evaluation with the source location of the string literal.

In the latter cases, tag values can be preserved when performing pointer arithmetic.

The (arguably) expanded treatment of backing arrays and string literals as potentially non-unique objects in issue 2753 lead to the question how the resulting address comparisons are treated during constant evaluation.

Subclause 7.7 [expr.const] bullet 5.24 specifies:

An expression E is a core constant expression unless the evaluation of E, following the rules of the abstract machine (6.9.1 [intro.execution]), would evaluate one of the following:

• ...
• a three-way comparison (7.6.8 [expr.spaceship]), relational (7.6.9 [expr.rel]), or equality (7.6.10 [expr.eq]) operator where the result is unspecified;
• ...

This phrasing is understood to refer to explicitly unspecified outcomes only. The treatment of an example such as

  constexpr bool b = "abc" == "abc";

is unclear, given that identical string literals may or may not yield distinct string literal objects.

The assumption that equality comparison of std::string_view would compare addresses as a short-cut before comparing the character sequence could not be confirmed (23.2.2 [char.traits.require], 23.3.3.8 [string.view.ops] paragraph 12).