On Fri, 13 Oct 2023, 11:58 Hadriel Kaplan via Std-Proposals, <std-proposals@lists.isocpp.org> wrote:

Back in 2019, https://wg21.link/p1819r0 was submitted for "interpolated literals". I believe it was reviewed in EWG-Incubator back then, and again in 2022. There appears to have been consensus for the author to keep working on it generally, but no consensus on the proposal's specific details.

I'd like to propose a different solution - but only for the specific idea of having f-strings in C++, as opposed to a general string-interpolation framework.

I've written up a brief strawman here: https://tinyurl.com/3tr8rv22

The basic idea is to just syntactically replace an f-string with its std::format() counterpart, as a new step between phase 6 and 7 of translation, right after concatenation of string-literals. I.e., an f-string would just be syntactic-sugar for std::format().

More-detailed rules are written in the linked proposal above. It even includes a way to add a customization point should that be desired by the WG, at which point it's a form of interpolation and could perhaps fully replace P1819.

It's arguably a bit hacky, but it should be far simpler than P1819 to implement, use, and maybe even standardize.

I'm looking for feedback on whether this is an idea worth pursuing, or whether it's a horrible idea and I should never raise it again.

I think this is worth pursuing.

I think this is interesting as well.

If you do submit a paper, please add SG16 to the audience and I'll be happy to schedule it for SG16 review.

Tom.

I don't care that it's coupled to std::format, that's consistent with f-strings being coupled to str.format() in Python. If there's a concern that we'd want to change them later to use std2::format, we could use f2"{var}" for that, or another prefix. I think the simplicity of your proposal is an advantage over a more extensive/extensible feature.

I don't really like being able to call functions, I think I'd feel more comfortable if you could only name lvalues, not use arbitrary expressions. The workaround isn't great though, e.g. with an immediately invoked lambda you'd have to use:

[c=calculate()]{ return f"{c}"; }()

instead of:

f"{calculate()}"

How much of the feature's usefulness is lost if it can only refer to lvalues, not evaluate expressions?

With reflection in C++ I think this could be done as a user defined literal, using f as a suffix instead of a prefix. But do we want to wait for that? Maybe. If the proposal was a pure library extension I'd say we should just do it, but as it requires changes to how source code is translated, maybe we don't want to make such fundamental changes as a stop gap that could be replaced by a decent reflection system.