Change string literals to use ' consistently (WONTFIX)

[Hixie]

One of the things that we originally left open in the Flutter style guide, but later narrowed down by popular demand, was string literal quotation. We now require that you use ' for literals and " for nested strings (as in, 'Hello ${name ?? "user"}!').

Any chance we could have the formatter enforce that?

[munificent]

I would love to have this be enforced in some tool somewhere, but it's outside of the formatter's core charter. It only touches non-semantic whitespace.

This avoids a lot of ratholes and, in particular, helps ensure the formatter's behavior is reversible. Consider this user path:

1. Start with formatted code.
2. Change some code.
3. Run the formatter.
4. Change the code back.
5. Run the formatter again.

The code at 5 should be the same as at 1. That's hard to guarantee if the formatter makes non-whitespace changes. (Though, in this specific case, I think it would be OK. But I think it's important for the formatter to have a simple charter and "only whitespace" is a good one.)

[Hixie]

I don't understand why "non-semantic whitespace" is ok to touch, and "non-semantic punctuation" is not.

The steps you describe would work just the same with the feature requested in this issue. Start with formatted code (i.e. using ' only), change it, run the formatter, change it back, run the formatter -- it'll be the same.

I would argue that whitespace is a lot more "semantic" than quotation marks. The analyzer right now destroys well-aligned code in a non-reversible way, which is a much bigger deal than whether or not it forgets which types of quotation marks were originally used. :-)

[munificent]

Touching anything other than whitespace opens up a can of worms. Things like:

"Hello 'mixed quotes' \"'" // Need to escape the single quotes now and unescape the double.
r"How do we fix 'this'?" // Can't escape these.
'Concatenate' 'these' // Do we join these automatically? What if there is a newline?
'L"o"t"s"of' "m'i'x'e'd quotes" // Then do we unify the quotes here?

function() /* 1 */ => /* 2 */ ... // Where does these comments go if we change to {}?
function() /* 1 */ { /* 2 */ return /* 3 */ short /* 4 */ ; } // These if we change to =>?

function() => throw "error!" // If we change this to {} do we add a return?

I think many of these are tractable, but they get fuzzy and the list of them is near infinitely wrong. That's great for a linter where a human can validate, customize, and tweak the output. It's not a good fit for a formatter that's designed to be run automatically on presubmit scripts over all user code.

[Hixie]

I mean, I can tell you simple answers for all these for the Flutter style. I don't see why they'd be any more intractable than whitespace issues. At the end of the day, they're part of the formatting rules that the project has to follow. Right now we use code review and post-hoc cleanup to make the code consistent; the more of that we can defer to a tool the better, IMHO. If the tool only does whitespace cleanup, then that just means we keep having to do some of the cleanup manually.