Python debug feature making f"{expr=}" equivalent to f"expr={expr}"

[BengtGustafsson]

Do we want this.

Pros and cons.

[hadrielk]

Pro's:

1. Relatively easy to perform in the preprocessor. (except see the Con's point 3 below)
2. No syntactic ambiguity issues, easy to parse.
3. Reduces user burden for trivial printf-style or log debugging, or for exception strings, etc.

Con's:

1. More syntactic "magic" - i.e., implicitly auto-generated stuff that's not obvious at first glance because it's not explicitly in the string.
2. A programmer error of adding a = will generate output that compiles successfully when it shouldn't. For example if they copy-paste from a auto some_member_var=foo(); incorrectly, into a F"val={some_member_var=}";.
3. Not sure if quoted-strings within the expression will make this complicated or not, since that aspect isn't decided yet for current f-strings. For example, not only do embedded quotes have to be escaped in their literal copies, but also {} braces need to be brace-escaped as well.

Did I miss anything?

[BengtGustafsson]

I agree that con #2 is not to be neglected: The more things that have a meaning the less things that are probably bugs the compiler can complain about.

Re con #3: Regardless of how LEWG/EWG decide on handling escaping of quotes and braces in expression-fields this should not affect this particular idea, the = is always after any of those nested literals or brace levels have ended.

[Mick235711]

Did I miss anything?

This syntax is actually ambiguous since you can have a valid expression ending in = today, not just in mis-pasting:

struct X
{
    void operator==(int);
    void operator=(int);
};
template<>
struct std::formatter<void (X::*)(int), char> { /* ... */ };
F"Test {&X::operator==}"  // <- {(&X::operator==)} or {(&X::operator=)=}?

Though, I'm confident absolutely no one writes code like this, and this can be resolved by simply requiring a parenthesis if the expression ends in =. Just mentioning it in case someone ask about potential conflicts.

[BengtGustafsson]

Thanks for pointing this out. I forgot about those nasty take-the-address-of-an-operator cases where almost any token can end an expression.

It seems a rather ridiculous thing to do to format the address of an assignment operator or comparison operator so I don't know, it seems fairly useful to use the = syntax as in Python, and as you remarked, if you really want to format the address of one of the affected operators you can use a parenthesis.

[BengtGustafsson]

Actually, if tokenization is used this would only react to &operator= as == is a separate token, as are all the other assignment operators as well as !=.

This means that the extracted expression is actually &operator which always a syntax error, so apart from the possible confusion in this very odd case there is no big problem, the address of one operator can never transmogrify to the address of another.