FWIW, that's not quite correct. For example, a string literal passed as a fmt argument won't be moved to the heap.

The upcoming Go 1.25 release has some related improvements that help strings in more cases. See for example https://go.dev/cl/649079.

Not quite - if the function accepting interface{} can be inlined (and other heuristics are groovy), then it won't escape.

Trivial example but it applies to real-world programs:

    > cat main.go
    package main
    
    import "github.com/google/uuid"
    
    func main() {
            _ = foo(uuid.NewString())
    }
    
    func foo(s any) string {
            switch s := s.(type) {
            case string:
                    _ = "foo:" + s
            }
            return ""
    }
    
    # Build with escape analysis
    > go build -gcflags="-m=2" main.go
    # command-line-arguments
    ./main.go:9:6: can inline foo with cost 13 as: func(any) string { switch statement; return "" }
    ./main.go:5:6: can inline main with cost 77 as: func() { _ = foo(uuid.NewString()) }
    ./main.go:6:9: inlining call to foo
    ./main.go:6:24: uuid.NewString() does not escape
    ./main.go:6:9: "foo:" + s does not escape
    ./main.go:9:10: s does not escape
    ./main.go:12:14: "foo:" + s does not escape

But the &str at the end is an additional heap allocation and causes an additional pointer hop when using the string. The only reason the function returns a pointer to a string in the first place is so that the nil check at the beginning can return nil. The calling code always checks if the result is nil and then immediately dereferences the string pointer. A better interface would be to panic if the argument is nil, or if that's too scary then:

    func (thing *Thing) String() (string, bool) {
        if thing == nil {
            return "", false
        }
        str := ...
        return str, true
    }

[^1]: As opposed to profile that collect data only when activated, like the CPU profile. The heap profile is active from the beginning if `MemProfileRate` is set.