Reference to string literals in Go

Taking the address of a literal (string, number, etc) is illegal because it has ambiguous semantics.

Are you taking the address of the actual constant? Which would allow the value to be modified (and could lead to a runtime error) or do you want to allocate a new object, copy the constant over and get the address to the new version?

This ambiguity does not exist in the case of test2 since you are dealing with an existing variable of which the semantics are clearly defined. The same would not work if the string was defined as const.

The language spec avoids this ambiguity by explicitly not allowing what you are asking for. The solution is test2. While it is slightly more verbose, it keeps the rules simple and clean.

Of course, every rule has its exceptions, and in Go this concerns composit literals: The following is legal and defined as such in the spec:

func f() interface{} {
    return &struct {
        A int
        B int
    }{1, 2} 
}

For the question of the best solution for your situation of passing around "static" strings,

1. Pass the string type instead of *string.
2. Don't make assumptions about what is going on behind the scenes.

It's tempting to give the advice "don't worry about allocating strings" because that's actually true in the case you're describing where the same string is passed around, perhaps many times. It general though, it's really good to think about memory use. It's just really bad to guess, and even worse to guess based on experience with another language.

Here's a modified version of your program. Where do you guess that memory is allocated?

package main

import "fmt"

var konnichiwa = `こんにちは世界`

func test1() *string {
    s := `Hello world`
    return &s
}

func test2() string {
    return `Hej världen`
}

func test3() string {
    return konnichiwa
}

func main() {
    fmt.Println(*test1())
    fmt.Println(test2())
    fmt.Println(test3())
}

Now ask the compiler:

> go tool 6g -S t.go

(I named the program t.go.) Search the output for calls to runtime.new. There's only one! I'll spoil it for you, it's in test1.

So without going off on too much of a tangent, the little look at the compiler output indicates that we avoid allocation by working with the string type rather than *string.