`strip_string_quotes` should be enabled by default

[guillermojp]

I think strip_string_quotes should be True by default to avoid unforeseen changes with regards to versions below 8.x.

In my use case, I was using this in my CI/CD, and this caused quotes to be propagated and to break existing functionality.

It's essentially my fault because I didn't have a static version for the python-hcl2 package, but it might still be worthwhile to add as an issue here.

Thanks! 😄

[kkozik-amplify]

We've decided to set strip_string_quotes to False by default for content fidelity and disambiguity. For example, after parsing a list containing both strings and integers (or floats, or plain identifiers or bools) to JSON, you can't tell which one is which. This is also crucial in JSON -> HCL2 reverse transformation.

FWIW, there's a migration guide.

(edit - I'll keep this issue open for visibility)

[livingstaccato]

Not arguing either way, but two measurements that might help whoever decides.

What the option does now. On 8.1.3, combined with preserve_heredocs=False,
it is exactly "remove the surrounding quotes and resolve the escapes" — the
value it yields is what you get by doing that yourself to the quoted form. That
holds for quoted literals, both heredoc kinds, and expressions, which keep their
inner quotes after #313:

same  'x = "quote \"in\" here"'   off='"quote \\"in\\" here"'  on='quote "in" here'
same  'x = "nl\nhere"'            off='"nl\\nhere"'            on='nl\nhere'
same  'x = <<EOT\nline1\nline2\nEOT\n'  off='"line1\\nline2"'  on='line1\nline2'
same  'x = "<<EOT\nbody\nEOT"'    off='"<<EOT\\nbody\\nEOT"'   on='<<EOT\nbody\nEOT'
same  'x = upper("a")'            off='${upper("a")}'          on='${upper("a")}'

So after 8.1.3 there is no longer a semantic surprise hiding in the option
itself, which was the case in 8.1.0–8.1.2 (#308/#310).

What defaulting it on would cost. hcl2/utils.py:46 already records it:
round-trip through from_dict/dumps is not supported with this option, since
the deserializer needs the quotes to tell a string from an identifier. That
makes load → modify → dump — the thing v8 was built for — the case that would
break, which seems like the real tension in this request rather than the value
shape.

If the default stays as it is, the reported surprise might be worth addressing
in the docs instead: the v7→v8 migration guide mentions the option, but not that
it is the single flag standing between v8's output and the v7-shaped values most
existing scripts expect.

---

Researched with AI assistance; the measurements above were executed rather than inferred, and reviewed and approved by me.