Nim: [RFC] strformat.% should be gone

Created on 13 Jan 2018  路  10Comments  路  Source: nim-lang/Nim

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:

  1. It is extremely unlikely that anyone is currently using $ with a string literal.
  2. $ is already known to be a stringification operator, so $"myInterpolatedString" would make much more sense visually.

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 &.

All 10 comments

I think having $ mean "formatting" and "stringification" would be far too confusing.

I will repeat what I proposed already:

  • Move 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.

7071 addresses the issue that caused %to be introduced in the first place

Using $ 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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

teroz picture teroz  路  3Comments

awr1 picture awr1  路  3Comments

SolitudeSF picture SolitudeSF  路  3Comments

juancarlospaco picture juancarlospaco  路  3Comments

zaxebo1 picture zaxebo1  路  4Comments