Related Issues

• x/tools/gopls: support conversion between raw and interpreted string literals #51200 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

@merrickclay gopls already supports this: when querying code actions inside an interpreted literal, you should have an option to convert to a raw string literal, and vice-versa.

(this was #51200)

Let me know if you have any ideas to make this more discoverable.

This proposal is to make this analysis run without any interaction from the developer and provide suggestions, like the simplify ranges analyzer does.

CC @adonovan

We have been talking about which code actions should be presented as quick fixes.

One of the heuristics we discussed about was that the quick fix should always improve the code. In this case, that does not apply, because there will always be a code action to translate format.

The other heuristics we discussed were:

• Frequency: this should be an action that the user frequently wants to apply.
• Accuracy: the fix always succeeds.

This DOES meet those heuristics.

Interpreted string literals with escaped double quotes and/or backslashes unnecessarily reduce readability.

This is less a fact than an opinion, and I suspect a minority one at that. One could equally argue that double quotes permit escape sequences, making it easier and more concise to denote tabs, newlines, quotation marks, and all kinds of things that are difficult or even impossible to express in a raw string literal. In any case, double-quoted strings are the normal way to write string literals in Go, and that isn't something we could change at this point even if we wanted to.

I agree with @findleyr that the double-quote-to-backquote transformation doesn't make sense as a quick fix because it doesn't unequivocally improve the code, as evidenced by the fact that gopls offers the inverse operation too.