> This is the sort of change that adds complexity to the language but reduces complexity in the code written in the language. We take those
An admirable statement of policy, but I'm not sure it's possible. Adding complexity to the language means there are more gotchas and edge-cases that a programmer must consider, even if they don't use the feature in question.
Depends on case to case basis. I wouldn't generalize it to every case. As a daily C++ engineer, I think overall many features added over the years have mostly been positive. There are features that I don't use and I don't think it really affects much. That said, I do get the sentiment of language becoming too syntactically complex.
I like this feature as string formatting is something frequently used and this certainly looks cleaner and quicker to write.
> Adding complexity to the language means there are more gotchas and edge-cases that a programmer must consider, even if they don't use the feature in question.
Since this is C++, this is not a problem we have to consider
This is a meme by now, yet it isn't as if Python 3.13 is a simple as Python 1.0, Java 23 versus Java 1.0, .NET 9 with C# 13 versus .NET 1.0 with C# 1.0 and a Framework reboot,....
C# has already enough material for pub Quiz, and no, not all of them are syntatic sugar, and require deep knowledge of the .NET runtime, and the way it interacts with the host platforms.
I imagine you never went too deep into unsafe, cross language interop, lambda evolution since the delegate days, events infrastructure, pluggable GC, RCW/CCW, JIT monitoring, the new COM replacement, how the runtime and language features differ across .NET Framework, Core, .NET MicroFramework, UWP, AOT compilation, Mono, .NET standard versus Portable Class Libraries, CLS friendly libraries,...
On top of that, all the standard frameworks that are part of a full .NET install on Visual Studio, expected that most C# developers know to at least have some passing knowledge on how to use them.
For other readers - more than half of these are irrelevant.
Writing general purpose application code rarely involves thinking about implications of most of these (save for NAOT as of lately I suppose).
Writing systems C# involves additional learning curve, but if you are already familiar with C++, it comes down to understanding the correct mapping between features, learning strengths and weaknesses of the compiler and the GC and maybe doing a cursory disassembly check now and then, if you care about it.
Yes of course, and I mean it somewhat seriously - C++ engineers are used to the language being too complex for anyone to completely understand. It's worth some more incremental language complexity to support niceties like fstrings without additional overhead.
how would this work with internationalized strings? especially if you have to change the order of things? You'd still need a string version with object ordering I would think
The question was, how would you use this if you have i18n requirements. Format strings are normally part of a translation. I think the bad answer is to embed the entire f-string for a translation as usual, except this can't work because C++ f-strings would need to be compiled. The better answer is, don't use f-strings for this because you don't want translators to monkey around with code and you don't want to compile 50 versions of your code.
Even if you told them, "just copy the names from the original string" it's still asking for trouble, and maybe even security holes if they don't follow instructions. But the biggest problem with the idea is surely that the strings need to be compiled.
Do what? Allow translators to reorder the appearance of arguments in a translated format string? It's a completely routine (and completely necessary) feature when
doing translations.
An admirable statement of policy, but I'm not sure it's possible. Adding complexity to the language means there are more gotchas and edge-cases that a programmer must consider, even if they don't use the feature in question.