The new strformat.% operator introduces unnecessary friction. Not only it collides with json.%, it doesn't have any visual meaning, nor it is introduced to the newcomers as some almost-built-in operator like & and $ for working with strings.
The problem of collision with json module is underestimated, imo. import smth except % is not a nice solution when copying code from a file where stformat.% used to work, to a file where json.% used to work. Since both modules are stdlib, they should play nicely with each other.
As a solution to this problem I would recommend introducing the $ macro overloaded by nkStrLit, while reducing existing $(s: string) to match only against non-literal values. As a next step, new $ interpolating macro could be brought to system.nim.
Reasoning:
$ with a string literal.$ is already known to be a stringification operator, so $"myInterpolatedString" would make much more sense visually.I think having $ mean "formatting" and "stringification" would be far too confusing.
I will repeat what I proposed already:
strformat.% to a strformat.ops module so that importing this % operator is done explicitly.Leaving % alive no matter which module it resides in doesn't solve the conflict problem. Please, don't make stdlib conflict with itself.
I think having $ mean "formatting" and "stringification" would be far too confusing.
"formatting" is a wrong word here. Change it to "string interpolation" and it should make a lot more sense.
%to be introduced in the first placeUsing $ as proposed in this RFC could be vaguely presented as calling $ to stringify an expression. This is always how I've informally interpreted the use of $ in the formatting language used by strutils.format.
Given #7082, I'd propose replacing {} with ${}:
import json except `%`
import strformat
var node = %* {"name": {"key": "value"}}
echo %"""Node: ${node{"name", "key"}}"""
...instead of...
import json except `%`
import strformat
var node = %* {"name": {"key": "value"}}
echo %"""Node: {node{"name", "key"}}"""
Inasmuch as "other people are doing it that way" is a thing, which it's not, this is the syntax ECMAScript, Scala, Groovy, and others are doing for their string interpolation markers.
If I was the hobgoblin of little minds, I'd do...
import json except `%`
import strformat
var node = %* {"name": {"key": "value"}}
echo %"""Node: $(node{"name", "key"})"""
...to make it look like $ was being called to stringify the expression node{"name", "key"} in the name of foolish consistency.
As far as the name of the proc/template, I'd tepidly prefer it to be named f.
This would give me the chance to do:
import json
import strformat
var node = %* {"name": {"key": "value"}}
echo f"""Node: {node{"name", "key"}}"""
...or...
import json
import strformat
var node = %* {"name": {"key": "value"}}
echo F"""Node: {node{"name", "key"}}"""
...and be insensitive to case.
I proposed an unary & since string interpolation results in a concat expression conceptually. People objected that a & &"{f}" would look strange, ignoring the fact that such expressions come up rarely (you can always use &"{a} {f}" instead. I think think this is the best solution.
$ is already known to be a stringification operator, so $"myInterpolatedString" would make much more sense visually.
I doubt this can work. echo "abc" is rewritten to echo [$"abc"]
People objected that a & &"{f}" would look strange
That was me. If we offer both fmt and & then I'm happy with that (you proposed & before that was on the table).
I proposed an unary
&
That looks like an acceptable solution to me as well.
In fact, removing % until a good solution is found is better than making this mistake now, which would be hard to fix later on.
& doesn't make any sense to me as a "formatting" operator, % was the most reasonable symbol, as it was already used for a long time for strutils format.
I agree that except % is not excellent, but I think it's still better than a random &.
& makes sense as it constructs a concatenation expression. Eventually I also want to introduce unary % that constructs a "dollar string" expression for i18n purposes.
Most helpful comment
&doesn't make any sense to me as a "formatting" operator,%was the most reasonable symbol, as it was already used for a long time for strutils format.I agree that
except %is not excellent, but I think it's still better than a random&.