cty.StringVal always doubles $ in ${} output Pt2 about go-cty

[apparentlymart]

Hi @tcgbrett,

Sorry I missed this before.

The escaping you are concerned about is being done by nrqlBody.SetAttributeValue (in HCL), not by cty.StringVal.

Here's the SetAttributeValue function's implementation: https://github.com/hashicorp/hcl/blob/63067e819cb6e8044d34b0a32d198a4941f34e42/hclwrite/ast_body.go#L168-L179

It calls NewExpressionLiteral: https://github.com/hashicorp/hcl/blob/63067e819cb6e8044d34b0a32d198a4941f34e42/hclwrite/ast_expression.go#L63-L68

...which calls TokensForValue which then, after a few other calls I'm skipping over, escapes the given string: https://github.com/hashicorp/hcl/blob/63067e819cb6e8044d34b0a32d198a4941f34e42/hclwrite/generate.go#L220

That escapeQuotedStringLit function is the one doing the escaping: https://github.com/hashicorp/hcl/blob/63067e819cb6e8044d34b0a32d198a4941f34e42/hclwrite/generate.go#L367-L373

It does that because SetAttributeValue is for setting the attribute to a constant value, not for setting it to an arbitrary expression. hclwrite currently lacks a function for setting an attribute to be a string template, because it lacks any model of string templates beyond the minimum required to generate literal strings. The closest you can get with the current API is to use SetAttributeRaw, but that requires you to hand-write the individual tokens that the template expression is built from.

hclwrite's model of expressions was originally built around what Terraform needed for some of its work and so it's lacking various features for constructing arbitrary expressions. It should be possible in principle to add an API for building string template expressions, and other kinds of expressions, but that's a topic for HashiCorp's HCL repository, rather than this codebase.

I also can't promise that the Terraform team at HashiCorp (who are the primarily maintainers of HCL) will be able to prioritize this, both because in this repository I'm wearing my cty maintainer hat (this is a personal project that HashiCorp projects depend on, rather than a HashiCorp project) and because even when I'm wearing my Terraform team hat I'm not the one who decides the team's development priorities. Opening an issue in the HCL repository to discuss your use-case would probably be the best next step, though.