> Again sorry if I’ve misunderstood, but why is it impossible?
The difference is run-time vs compile-time checking. If you need more, read back up for the explanation I gave Julian, or try it out in another language for yourself.
> What you are talking about is not a literal. 0x11 is always the same thing.
So is the "Value = " in f"Value = ${value}". Obviously, the whole thing is not a literal. But, the literal value that is produced by that _expression_ is different from the literal value produced by plain "Value = ${value}", just like the value of the literal produced by 0x34 is different than the value of 8r34. Yes, parts of how it works are new, but stylistically it's not that different from these other prefix-based literals. Remember, the criticism was not that it's new in some way, just that it doesn't match "existing conventions and style."
> I think I am giving it a fair hearing.
I think you are too, but there were misconceptions in this thread earlier about what string interpolation actually is; that's what I was referring to. Sorry for the confusion.
> syntax highlighting would help, but shouldn't highlighting be an optional
> aid? If we need highlighting just to read the durned thing, there's
> something wrong
OK, yes, if you write intentionally obtuse code, your code will be hard to read. This is not an issue with the specific notation at hand, it is a general code quality concern. Replace any of your complex f"" examples with the equivalent code in .format and it is still bad code. But in the 99% of cases where people are using highlighting, the boundary between code and string literal is very clear, and your original complaint was that it's not.
One clear advantage of string interpolation is that it's harder to screw it up at runtime. With format, it is easy to write:
"hello world".format(3)
"hello %".format("world", "pony")
"%: Error '%' at line %. Saw % flowers, no bugs.".format(name, err, line, flowers, bugs)
And you won't even get so much as a warning that you provided too many or too few arguments. If you're not testing all the branches of your code and/or watching closely, you might never notice that you made this error. On the other hand, it's impossible to get the equivalent interpolation wrong in this way:
"hello \(world)"
There is no place to add or forget arguments. "hello \()" wouldn't compile (although "hello \("")" would).
It's also easier to maintain code with interpolation. Consider this scenario:
%: Error '%' at line %. Saw % flowers, no bugs.".format(name, err, line, flowers)
Say you need to add a count for bugs. It's easy (I've done it) to mess it up by writing one of the following:
%: Error '%' at line %. Saw % flowers, % bugs.".format(name, err, line, flowers)
%: Error '%' at line %. Saw % flowers, no bugs.".format(name, err, line, flowers, bugs)
And it actually takes a considerable amount of time to figure out what is wrong in this _expression_. This error is even more common when deleting %'s from the string.
String interpolation, on the other hand, requires only one edit to maintain:
"\(name): Error '\(err)' at line \(line). Saw \(flowers) flowers, no bugs."
"\(name): Error '\(err)' at line \(line). Saw \(flowers) flowers, \(bugs) bugs."