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))
./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)
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
}
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)))
}
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)
Further reading 📚
- proposal: Go 2: make constants and literals addressable · Issue #28681 · golang/go
- proposal: spec: add &T(v) to allocate variable of type T, set to v, and return address · Issue #9097 · golang/go
- proposal: expression to create pointer to simple types · Issue #45624 · golang/go
- go - Golang - Cannot take address of variable in struct error, untyped string constant - Stack Overflow
- pointers - Find address of constant in go - Stack Overflow
- pointers - Reference to string literals in Go - Stack Overflow
- Assigning values to pointer types in a go struct - Stack Overflow
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.
Top comments (1)
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.
samber / lo
💥 A Lodash-style Go library based on Go 1.18+ Generics (map, filter, contains, find...)
lo - Iterate over slices, maps, channels...
✨
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
andmaps
). I feel this library is legitimate and offers many more valuable abstractions.See also:
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