comment on rust-lang/rfcs#2795 which i think is actually completely wrong, so cancelling
Do i understand correctly that this would be a special case in the language, understood by the compiler itself? That this isn't a change to the definition of the format_args! macro?
Would this be specific to format_args!, or could syntax like this be used by other, user-written, macros, which don't build on format_args!?
I understand that format_args! is currently special, implemented as a compiler built-in, rather than as a real macro. However, i've always seen this as an unfortunate wart, something that had to be done because we needed good print statements, and the macro system wasn't strong enough to implement them yet. It would be nice to remove that wart one day. Even while it's in place, it's useful to be able to gloss over it, and describe format_args! as just another macro, not doing anything any other macro couldn't do.
If i've understood correctly, then adding this feature involves accepting quite a large break in the regularity of the language.
On the other hand, the gain in functionality seems truly marginal to me. I note that Java doesn't have template strings, and is the world's most-used language; Python only got them with 3.6, in 2016, and was widely considered the best language for beginners for at least a decade before that; C and C++ don't have them, and have been dominating systems programming for a generation. Go doesn't have them, and is famed for being easy for beginners to pick up and be productive in.
This isn't because string formatting in these languages is great (Rust's is already better!) - i think it's because string formatting is such a small part of any real program. Yes, the first thing a newcomer does is print "Hello, world", but how many more print statements do they write in their next hundred, ten thousand, million lines of code? How much of their effort and struggle goes into print statements, as opposed to all the rest?
Moreover, i think this proposal falls into the trap of equating better ergonomics with "less typing", with a side of "less eyeball jumping". Ergonomics is about difficulty of understanding, not simply seeing, and adding more magic does not aid understanding.