proposal: Go 2: string interpolation

[sirkon]

Introduction

For ones who don't know what it is:

Swift

let multiplier = 3
let message = "\(multiplier) times 2.5 is \(Double(multiplier) * 2.5)"
// message is "3 times 2.5 is 7.5"

Kotlin

var age = 21

println("My Age Is: $age")

C#

string name = "Mark";
var date = DateTime.Now;

Console.WriteLine($"Hello, {name}! Today is {date.DayOfWeek}, it's {date:HH:mm} now.");

Reasoning of string interpolation vs old school formatting

I used to think it was a gimmick but it is not in fact. It is actually a way to provide type safety for string formatting. I mean compiler can expand interpolated strings into expressions and perform all kind of type checking needed.

Examples

variable := "var"
res := "123\{variable}321" // res := "123" + variable + "321"

return errors.New("opening config file: \\{err}") // return errors.New("opening config file: " + err.Error())

var status fmt.Stringer
…
msg := "exit status: \{status}" // msg := "exit status: " + status.String()

v := 123
res := "value = \{v}" // res := "value = " + someIntToStringConversionFunc(v)

Syntax proposed

• Using $ or {} would be more convenient in my opinion, but we can't use them for compatibility reasons
• Using Swift \(…) notation would be compatible but these \() are a bit too stealthy

I guess {…} and \(…) can be combined into \{…}

So, the interpolation of variable variable into some string may look like

"<prefix>\{variable}<suffix>"

Formatting also has formatting options. It may look like

"<prefix>\{variable[:<options>]}<suffix>"

Examples of options

v := 123.45
fmt.Println("value=\{v:04.3}") // value=0123.450

v := "value"
fmt.Println("value='\{v:a50}'") // value='<45 spaces>value'

etc

Conversions

There should be conversions and formatting support for built in types and for types implementing error and fmt.Stringer. Support for types implementing

type Formatter interface {
    Format(format string) string
}

can be introduced later to deal with interpolation options

Pros and cons over traditional formatting

Pros

• Type safety
• Performance (depends on the compiler)
• Custom formatting options support for user defined types

Cons

• Complication of a compiler
• Less formatting methods supported (no %v (?), %T, etc)

[latitov]

Why can't we use just ${...}? Swift already has one syntax, JavaScript and Kotlin another, C# yet another, also Perl... Why invent one more variation? Wouldn't it be better to stick to the one most readable and already existing?

[sirkon]

Why can't we use just ${...}? Swift already has one syntax, JavaScript and Kotlin another, C# yet another, also Perl... Why invent one more variation? Wouldn't it be better to stick to the one most readable and already existing?

Because we may have existing strings with ${…}. I do, for instance.

And \{ is not allowed right now.

[ianlancetaylor]

This doesn't seem to have a big advantage over calling fmt.Sprintf.

[sirkon]

This doesn't seem to have a big advantage over calling fmt.Sprintf.

Yes, it doesn’t besides full type safety, better performance and ease of use. Formatting done right for a language with static typing.

[ianlancetaylor]

As far as I can tell this proposal isn't any more type safe than using fmt.Sprintf with %v. It's essentially identical with regard to type safety. I agree that a careful implementation could have better performance in many cases. I'm agnostic on ease of use.

[ianlancetaylor]

In order to implement this we would have to write, in the language spec, the exact formatting to use for all types. We would have to decide and document how to format a slice, an array, a map. An interface. A channel. This would be a significant addition to the language spec.

[latitov]

I think it's one of those questions where both ways have the right to exist, and it's just up to the decision makers to decide. In Go, the decision has been already made, quite a long time ago, and it works, and it's idiomatic. That's fmt.Sprintf with %v.

Historically, there are languages where interpolation inside a string has been present from the very beginning. Notably it's Perl. That's one of the reasons why Perl became so popular, because it was a super-convenient compared to sprintf() in C et al. And the %v wasn't invented then yet. And then there are languages where the interpolation was present, kind of, but was inconvenient syntactically, think of "text" + v1 + "text". JavaScript then introduced backtick-quoted literals, which are multi-line, and support interpolation of arbitrary expressions inside ${...}, which was huge improvement compared to "text" + v1 + "text". The Go too has backtick multi-line literals, but without ${...}. Who copied whom I don't know.

I don't agree with @ianlancetaylor that support of this will need substantial effort. In fact, fmt.Sprintf with %v does exactly this, doesn't it? It looks for me like a different syntax wrapper to exactly the same thing under the hood. Am I right?

But I do agree with @ianlancetaylor that using fmt.Sprintf with %v is as convenient. It's also exactly the same in length on the screen, and, what is IMHO very important - is already idiomatic for Go. It kind of makes Go Go. If we copy-implement every other feature from every other language, then it will no longer be Go, but every other language.

There's one more thing. From my long experience with Perl, where string interpolation was present from the very beginning, I can say that it's not that perfect. There's a problem with that. For simple and trivial programs, and probably for 90% of all programs, string interpolation of variables works just fine. But then, once in a while, you get a var=1.99999999999, and want to print it as 1.99, and you can't do that with standard string interpolation. You either need to do some conversion beforehand, or... Look into the docs, and re-learn long forgotten sprintf() syntax. Here is the problem - using string interpolation allows you to forget how to use sprintf()-like syntax, and probably it's very existence. And then when it's needed - you spend too much time and effort to do simplest things. I am talking in Perl context, and it was a decision of language designer(s) to do so.

But in Go, a different decision has been made. The fmt.Sprintf with %v is already here, it's as convenient, as short as interpolated strings, and it's idiomatic, in that it's in the docs, in examples, everywhere. And it doesn't suffer from the problem of eventually forgetting how to print 1.99999999999 as 1.99.

Introducing proposed syntax will make Go a little more like Swift and/or more like JavaScript, and some may like that. But I think this particular syntax will not make it better, if not a little worse.

I think that existing way to print things should stay as it is. And if someone needs more - then there are templates for that.

[mvdan]

If part of the argument here is safety at compile time, I don't agree that's a compelling argument; go vet, and by extension go test, have been flagging incorrect uses of fmt.Sprintf for a while.

It's also possible to optimize for performance today via go generate, if you really wish to do so. It's a tradeoff that's not worth it most of the time. I feel like the same applies to greatly expanding the spec; the tradeoff is generally not worth it.

[kaey]

Allowing function calls inside interpolated strings would be unfortunate - too easy to miss.
Not allowing them is another unnecessary special case.