I'm a HUGE fan of f-strings and I think they should be added to more or less every language in existence. (This is just to show how much I like f-strings, not to be taken literally) `printf`-style format strings seem outdated: why use format strings when I can put my variables IN THE STRING? I want the result of `x+y` to be put {HERE} in this string. Well, just write `"This is here: {x+y} blah"` — it makes perfect sense and immediately lets me see what the resulting strings generally look like.

Basic usage is a no-brainer: write your string, put variables or short expressions in curly braces, add `printf`-style format specifiers after the colon. This is also great because it's a natural extension of `printf`-style format strings.

Of course you can write complicated and confusing f-strings. But then you can write complicated and confusing... anything, really. Many programming languages have extremely weird quirks and cases where basic syntax can be transformed into an unreadable monstrosity, like C syntax for pointers to functions and arrays.

Sure, this increases the language's complexity, but you don't have to use all of it to reap the benefits.

▲ Izkata 2 hours ago | parent | next [-]

Those aren't the only two options. Like GP I don't like f-strings, but there was something introduced before that: the format function.

  "The thing is {foo}, and also {foo} again".format(foo=x+y)

It also supports positional with empty {}. And like f-strings, you can put formatting information after a colon.

%-based printf-style did also have named variables like this but it seemed less known.

	▲	circuit10 17 minutes ago \| parent [-]
		This is still significantly more clunky than f-strings, especially when you're writing them a lot for debugging purposes

▲ layer8 2 hours ago | parent | prev [-]

> why use format strings

Because these are used for locale-specific configuration data. `"This is here: {x+y} blah"` on the other hand isn’t a string (mere data), it’s a program, because you can have arbitrary expressions inside the braces. You don’t want to repeat the `x+y` in each localization file.

I have nothing against ergonomic program constructs for composing strings, but please let’s not confuse such program constructs with mere string literals.

▲

zdragnar an hour ago | parent [-]

If your string needs to be presented in multiple locales, you probably want to go a step further and use something like the ICU syntax and a proper parser and formatter rather than rely on manually formatting things yourself. Otherwise, that dynamic data is going to give you headaches when you have to deal with plurals and genders and such.

	▲	layer8 an hour ago \| parent [-]
		I’m not sure what you mean by manual formatting. You do need a place in your program where you fill in the parameters into the respective localized string template. I agree that the printf format syntax is somewhat limited for localization [0]. But whatever localization string format you use, you don’t want arbitrary expressions embeddable within it. [0] though GNU libc does let you extend it: https://sourceware.org/glibc/manual/latest/html_mono/libc.ht...