DEV Community

Jacob Hummer
Jacob Hummer

Posted on • Edited on • Originally published at jcbhmr.me

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

Further reading 📚

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 in golang/go#45624 (comment)

Reinvent your career. Join DEV.

It takes one minute and is worth it for your career.

Get started

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

👋 Kindness is contagious

Immerse yourself in a wealth of knowledge with this piece, supported by the inclusive DEV Community—every developer, no matter where they are in their journey, is invited to contribute to our collective wisdom.

A simple “thank you” goes a long way—express your gratitude below in the comments!

Gathering insights enriches our journey on DEV and fortifies our community ties. Did you find this article valuable? Taking a moment to thank the author can have a significant impact.

Okay