DEV Community

Cover image for 馃敡 Fix "cannot take address of <value>" in Go
Jacob Hummer
Jacob Hummer

Posted on

馃敡 Fix "cannot take address of <value>" in Go

This is a summary of my Googling for future me or anyone else.

fmt.Println(&"Hello")
fmt.Println(&true)
fmt.Println(&15)
fmt.Println(&fmt.Sprint(123))
Enter fullscreen mode Exit fullscreen mode
./prog.go:8:15: invalid operation: cannot take address of "Hello" (untyped string constant)
./prog.go:9:15: invalid operation: cannot take address of true (untyped bool constant)
./prog.go:10:15: invalid operation: cannot take address of 15 (untyped int constant)
./prog.go:11:15: invalid operation: cannot take address of fmt.Sprint(123) (value of type string)
Enter fullscreen mode Exit fullscreen mode

You currently can't get the address of literals or function return values in Go. You can, however, get the address of function parameters which means you can create a helper ptr() function to turn any value into a pointer. 馃槈

func ptr[T any](value T) *T {
  return &value
}
Enter fullscreen mode Exit fullscreen mode
func ptr[T any](value T) *T {
  return &value
}
func main() {
  fmt.Println(ptr("Hello"))
  fmt.Println(ptr(true))
  fmt.Println(ptr(15))
  fmt.Println(ptr(fmt.Sprint(123)))
}
Enter fullscreen mode Exit fullscreen mode

Of course, you could always stuff these values into a variable and &theVariable. 馃檮 But who wants to clutter their code with extra one-time intermediary variables?

a := "Hello"
fmt.Println(&a)
b := true
fmt.Println(&b)
c := 15
fmt.Println(&c)
d := fmt.Sprint(123)
fmt.Println(&d)
Enter fullscreen mode Exit fullscreen mode

Other resources

Judging from the past 1.5 years, I appear to be writing this function about once every second month, when I need it in a new package. The need especially arise with pointers to strings in unit test files, I've noticed.

Admittedly, I work a lot with code generated from API specifications. That code tend to use *string a lot, since it can't be certain that nil and empty string are equivalent (and rightly so, they aren't).

It's not very annoying, but does feel a bit like I'm littering my packages with this function, so not having to write it would be welcome. I do realise I can put it in a package I import, but that also seems overkill for a one-liner.

鈥 perj -- golang/go#45624 (comment)

Top comments (1)

Collapse
 
ccoveille profile image
Christophe Colombier

Yes, Go was struggling with situation like this.

I faced it so many times in unit tests 馃槄

I would like to suggest you this lib that tries to address many issues of the Go language with generics.

GitHub logo samber / lo

馃挜 A Lodash-style Go library based on Go 1.18+ Generics (map, filter, contains, find...)

lo - Iterate over slices, maps, channels...

tag Go Version GoDoc Build Status Go report Coverage Contributors License

samber/lo is a Lodash-style Go library based on Go 1.18+ Generics.

This project started as an experiment with the new generics implementation. It may look like Lodash in some aspects. I used to code with the fantastic "go-funk" package, but "go-funk" uses reflection and therefore is not typesafe.

As expected, benchmarks demonstrate that generics are much faster than implementations based on the "reflect" package. Benchmarks also show similar performance gains compared to pure for loops. See below.

In the future, 5 to 10 helpers will overlap with those coming into the Go standard library (under package names slices and maps). I feel this library is legitimate and offers many more valuable abstractions.

See also:

  • samber/do: A dependency injection toolkit based on Go 1.18+ Generics
  • samber/mo: Monads based on Go 1.18+ Generics (Option, Result, Either...)

Why this name?

I鈥

Here is your pointer helper for example
pkg.go.dev/github.com/samber/lo#Fr...

Please note Go core developers are aware of these, and try adding things. slice packages is a great recent addition.

pkg.go.dev/slices