Only if the calling function does something with the pointer (which it generally won't, if err is non-nil). If the calling code does do something with the pointer even when err is non-nil, then either
(a) the value of the pointer is meaningful, and this is fine; or
(b) there's a logic error in the calling code, which is a far more serious bug than a potential memory leak.
So I don't really see the problem here.
At least Go doesn’t use RAII, so inadvertently pinning a pointer won’t keep a socket open or a lock held.
The following toy example doesn't leak memory. Are you thinking of some other pattern that would leak memory? If so, what is it? I can only think of patterns where a logic error is also involved. That is, where the meaningless value of 'val' is used in code paths where err != nil.
func alwaysError() (*int, error) {
var dummy int
// We return &dummy even though it's a meaningless value.
// Will this cause a memory leak?
return &dummy, fmt.Errorf("An error")
}
func caller() {
val, err := alwaysError()
if err != nil {
fmt.Printf("Error\n")
// It won't! Because the value pointed to by 'val'
// can be GCed from this point on.
return
}
// never get here
fmt.Printf("Value %v\n", val)
//
// ...lots of code that uses *val...
//
}
In a language where destruction of an object often releases external resources (C++, for example, or Python or Rust to a lesser extent), this effect would be more dramatic. Imagine someone doing this in Python:
def func():
f = tmpfile(…)
err = do something
return f, err
But Go is a garbage collected language, and there is so such thing as “discarding” a pointer. Either it’s there or it isn’t, and this kind of leak has side effects. I find it baffling that the language designers and the community consider this acceptable.
(One thing I really like about Rust is that you can’t play fast and loose with lifetimes like this. If you have function taking &'a Vec<T> and you return &'a T, you can’t arbitrarily “discard” and leak that reference up the call chain. You need to genuinely get rid of it by the time the vector is gone.)