Can hand-written move function without runtime support take the ownership of an object entirely?

[Qingwei Li]

Take the following program as an example.

```go
c, err := getFtpConnection()
if err != nil {
return nil, err
}
go func(c2 *ftp.ServerConn) {
c2.List()
}(c)
// c will not be used later
```

let's add `move` function.

```go
func move[T any, PT *T](pp *PT) (res PT) {
res = *pp
*pp = nil
return
}

// Goroutine G1
c, err := getFtpConnection()
if err != nil {
return nil, err
}
go func(c2 *ftp.ServerConn) { // Goroutine G2
c2.List()
}(move(&c))
// c will not be used later
```

Would this `move` without runtime support make GC unable to reach the object pointed by `c` scanning from the stack of goroutine G? If it does, the ownership of object is entirely moved to goroutine G2. With the ownership transfering, freegc for `c2` in the end of goroutine G2 is feasible in cross-goroutine reference case.

[Qingwei Li]

replies are in link:  Re: [go-nuts] Does hand-written move function without runtime support can transfer the ownership of an object entirely?

[robert engels]

Some good info here https://blog.stephencleary.com/2010/02/q-should-i-set-variables-to-null-to.html#:~:text=Setting%20instance%20fields%20to%20null%20does%20not%20help%20the%20garbage,this%20is%20a%20rare%20situation.

On Feb 24, 2026, at 7:43 AM, 'Qingwei Li' via golang-nuts <golan...@googlegroups.com> wrote:

replies are in link:  Re: [go-nuts] Does hand-written move function without runtime support can transfer the ownership of an object entirely?

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/af0d34ff-c78c-4d86-97b6-0e7a347b1975n%40googlegroups.com.

[Robert Engels]

Also, there is no “ownership by routine” - the only time this might come into play is a system with "thread local" storage - which even then doesn’t isolate the object as it can still be shared with other threads to “escape” ownership.

There is no concept of ownership in a GC system - that is the point - the runtime manages all object lifecycles for you - if an object is reachable it is “alive” and if not, it will be garbage collected.

Note, this is orthogonal to concurrency issues involved when sharing objects across Go routines.

Also, you can perform manual memory management in Go - but it is rarely needed unless interfacing with existing non-Go libraries.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/97151e98-d453-4ca6-9454-7abe8a27a6abn%40googlegroups.com.

[Qingwei Li]

Robert, thanks for your explanation. I have loosened the question in https://groups.google.com/g/golang-nuts/c/m_EyZtfnRRo/m/ZIY3MtzAAwAJ. These two conversations should be one but I happen to make it two by deleting old post and creating new one. Sorry for bothering.