proposal: spec: add simple string interpolation similar to Swift

[ianlancetaylor]

I propose a simple version of string interpolation similar to that in Swift. This is a simpler version of #34174 and #50554.

Proposal

In string literals we permit a new escape sequence \(. A valid \( must be followed a expression and a trailing ). Any unquoted ( in the expression must be balanced by a ) so that the compiler can locate the ) that terminates the \(.

The expression is evaluated in the context of the string literal. If it is not valid, the compiler reports an error. Multiple \( expressions in the string literal are evaluated from left to right.

The expression must evaluate to a single value. If the type of that value has a method String() string, that method is called to get a string value. Otherwise the expression must be a string, integer, floating-point, complex, or boolean value. Values of other types will be reported as an error.

1. If the expression has a string type, it is used as is.
2. If the expression is a constant expression it is converted (as described below) to an untyped string constant.
3. Otherwise the expression is converted (as described below) to a non-constant value of type string.

The original string "prefix\(expression)suffix" is then replaced by the expression ("prefix" + expressionAsString + "suffix").

Examples

    // Prints something like "Ken Thompson is 79 years old".
    fmt.Println("\(person.Name()) is \(person.Age()) years old")
    // Prints something like "The time is 2023-01-04 16:22:01.204034106 -0800 PST".
    // Note: calls the String method of time.Time.
    fmt.Println("The time is \(time.Now().Round(0))")

Formatting

Integer values are converted to strings in the obvious way.

Floating-point values are converted to strings with the equivalent of strconv.FormatFloat(f, 'g', prec, -1). This will need to be spelled out in the spec.

Complex values are converted to strings by converting the real and imaginary parts to R and I as with any float, and producing R+Ii or R-Ii.

Boolean values are converted to either "true" or "false".

Values of other types are not permitted.

Commentary

String interpolation is useful to avoid mistakes in complex formatting, as discussed in the earlier issues.

The earlier issues were caught up in complexity due to the desire to control formatting. However, 1) we already have fmt.Sprintf for arbitrary formatting; 2) even with simple string interpolation we can do formatting by writing code like "The average of \(len(values)) is \(strconv.FormatFloat(average, 'f', 32, 2))".

The syntax \(EXPR) is borrowed from Swift.

The type of the result ensures that interpolating variable values into a string can't produce an untyped string constant, but can only produce a non-constant string value. This will avoid implicit type conversions.

This proposal is backward compatible as currently using \( in a string causes a compilation error.

[johanbrandhorst]

The second example escapes both the opening and closing bracket, is this intentional?

[icholy]

Would interpolation be permitted in const strings?

[ianlancetaylor]

@johanbrandhorst Fixed, thanks.

[ianlancetaylor]

@icholy Without thinking about it too hard I would say yes, but that the expressions must be constant expressions. That would mean that they can't be function calls, only references to other constants. Not sure how useful that would be in practice.

[cespare]

One effect of this change would be to invalidate packages like https://pkg.go.dev/github.com/google/go-safeweb/safesql which rely on string literals not containing arbitrary expressions evaluated at runtime.

[ianlancetaylor]

@cespare Interesting point. We would want to say that the result of string interpolation is a non-constant value of type string. It would not be an untyped string constant. As such, it could not be passed to a function like safesql.New.

I added that to the proposal.

[apparentlymart]

My initial instinct was to be concerned about the lack of ability to customize the formatting of the built-in types, but:

• You already addressed that in the proposal and showed that it's possible to call functions like strconv.FormatFloat and fmt.Sprintf inside the interpolation sequences, if needed.

• In my day job I work on HashiCorp Terraform whose own language makes essentially the same tradeoff: interpolation like "blah-${foo}" works just like string concatenation but you can write "blah-${format("%05d", foo)}" to get formatted numbers. (format is essentially equivalent to Go's fmt.Sprintf).

  That compromise seems to have paid off in practice. A few times I've seen folks ask how to get formatted numbers in string interpolation, perhaps betraying that it isn't immediately intuitive that it's possible to use arbitrary functions in there, but folks seem to understand and accept it as a suitable answer once informed about it.

One smaller concern I have is that this proposal does not treat interpolation the same as string concatenation per the usual Go rules. Terraform gets away with treating this as string concatenation because there's an implicit conversion in its language from numbers and booleans to strings. It feels a little awkward that Go string interpolation would not follow the same rules as string concatenation, but not the end of the world. It might be interesting to consider the implications of changing the + operator when applied to a string and a non-string to follow the same conversion rules for consistency, but I don't think it's a deal-breaker.

Overall I think I like this and I expect it'll improve the readability of lots of examples of fmt.Sprintf in codebases I maintain, so 👍 (also recorded on the original comment, for ease of vote-counting) on reflection, despite my initial concerns.

[griesemer]

@ianlancetaylor @cespare I am all for keeping it simple and for this proposal to make the result of an interpolated string be a non-constant value of string type. But I don't understand the comments #57616 (comment) and #57616 (comment): If an interpolated string does only contain constant expressions (which by definition must be evaluated at compile-time) why would it be a problem if the resulting string is constant (of type string, or maybe even untyped string)? Such a string cannot ever change its value at run-time.

(Again, it may not be worth the trouble even if's not causing security issues, but I can imagine some uses for constant interpolated strings. For instance, var digits[len("\(1 << 63)")]byte // buffer for uint64 to string conversion.)

[griesemer]

@ianlancetaylor Can we make "s1\(x1)s2\(x2) ... sn\(xn)" behave exactly like "s1" + F(x1) + "s2" + F(x2) + ... + F(xn), where F is the spec-defined string conversion function for the permissible expression types? (I'm not sure if that's the proposals' intent already, or maybe I misunderstand @apparentlymart 's #57616 (comment) (his reference to the "smaller concern")).

If we do this, it's a) easy to specify the exact behavior (we just need to explain F in the spec), and b) we don't need some new special representation for interpolated strings in the implementation (syntax tree). The parser can trivially transform the string into a binary expression (of + operations) as needed.

As an aside, if F is defined to return a constant for constant expressions (and string or untyped string as desired), the resulting constant-ness and type of the interpolated string follows directly from existing rules, ensuring that we don't bake it some non-orthogonal inconsistency.