标签：#stdlib

Book: The Complete Guide to Go Programming Also by me: Hexagonal Architecture in Go — the companion book in the Thinking in Go series My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools Me: xgabriel.com | GitHub You reach for unsafe.Pointer to skip a copy. Maybe a []byte you want as a string without the allocation, maybe a struct you want to reinterpret as another. The code compiles. go vet stays quiet. Tests pass. Then, weeks later, under GC pressure, a rare crash shows up in a place that has nothing to do with your change. The Go unsafe package documentation is one long doc comment. It lists the conversions that are valid and warns that everything else is not portable and not guaranteed to keep working. The trouble is that "everything else" includes a lot of code that looks obviously correct. The rules are narrow on purpose. There are effectively four patterns you are allowed to write, and the standard library stays inside all four. Here they are, in the shape you will actually use them in Go 1.23+. The one fact under every rule unsafe.Pointer is a pointer the garbage collector understands. It keeps the object it points at alive and it moves with the object if the runtime relocates a stack. uintptr is a plain integer. The GC does not treat it as a reference. Convert a pointer to a uintptr , store that integer in a variable, and as far as the runtime is concerned nothing points at that memory anymore. That single fact is behind three of the four patterns. Every legal conversion either avoids uintptr entirely or keeps it inside one expression where the compiler can prove the pointer stays live. Pattern 1: reinterpret *T1 as *T2 with the same layout The first pattern converts a *T1 to *T2 when the two types have the same memory shape. You take the address, run it through unsafe.Pointer , and cast to the target pointer type. The standard library does exactly this in math.Float64bits : func Float64bits ( f float64

Book: The Complete Guide to Go Programming Also by me: Hexagonal Architecture in Go — the companion book in the Thinking in Go series My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools Me: xgabriel.com | GitHub You are wiring an HTTP router. You have a Server struct with a handler method, and you want to register it. So you write mux.HandleFunc("/users", srv.ListUsers) and it works. You never stop to ask what srv.ListUsers actually is as an expression. It is a method value. Go took the method, bound it to srv , and handed you back a plain func(http.ResponseWriter, *http.Request) . That binding is the thing doing the quiet work in half the handler wiring you write. There is a second form the Go spec gives you, and most Go developers never type it on purpose: the method expression, Server.ListUsers , which produces a function that takes the receiver as its first argument. Same method, different shape, different use. These two live in the Go spec and they are worth telling apart, because the compiler will happily let you reach for the wrong one. The two forms, side by side Start with a small type and one method. type Greeter struct { prefix string } func ( g Greeter ) Say ( name string ) string { return g . prefix + " " + name } A method value binds the receiver now: g := Greeter { prefix : "hello" } say := g . Say // method value, receiver g is captured fmt . Println ( say ( "ana" )) // "hello ana" say has type func(string) string . The receiver is gone from the signature because Go already stored g inside the closure. Call it later, from anywhere, and it still remembers g . A method expression leaves the receiver open: say := Greeter . Say // method expression, no receiver yet fmt . Println ( say ( g , "ana" )) // "hello ana" say here has type func(Greeter, string) string . The receiver became the first parameter. You supply it at the call site, every time. Same method name. g.Say reads the value g ; Greeter.Sa