I'm pretty sure boost::format can do this, though not inline in the string. Do we really need more complexity in cpp? isn't it complex enough?
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.
Since this is C++, this is not a problem we have to consider
C++ has lots of features that interact with each other in unexpected ways that could leak memory or access freed memory etc.
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.
They simply do not matter. For example - CLS-compatiblity, seriously? I'd return the favour and ask the interviewer why they disagree with the .NET's team stance that this lost relevance in early .NET versions more than a decade ago.
There are main framework and features to be aware of, there are some that may be relevant to legacy codebases you must avoid like fire, and there are those to which the only appropriate response would be "this never existed, if it did, forget about it".
(to Pjmlp - please do not equate knowing the terms with understanding them, and stop bringing up whatever was left by wayside of history to people who should have no business being bothered by this nonsense, thank you)
I do whatever I please, feel free to ignore my comments, downvote them, or whatever goes on your heart regarding them.
And while I expect any junior not to know half of them, anyone claiming to be a senior better have an answer, regardless of what I throw at them.
Naturally I don't expect anyone versed in desktop frameworks to master backend and vice-versa, but they better know the bits that relate to desktop in that case, across the whole stack.
I like this feature as string formatting is something frequently used and this certainly looks cleaner and quicker to write.
Rusts string formatting machinery does not require any heap allocations at all, you can for example impl fmt::Write for a struct that writes directly to a serial console byte-by-byte with no allocations, and then you have access to all of rusts string formatting features available to print over a serial console!
I'm not sure about the horrifying and dangerous extensions part though, I'm not really a C++ expert so I don't know if there's a better way to do what they want to do.
Formatting on the foreground thread would be a non-starter.
fmt library can also do something similar, but still requires the complexity of adding the library and passing arguments.