== In Go, _unsafe.Pointer_ is a built in type in the compiler Here is something that I didn't fully grasp and understand until I did some digging in the Go compiler as part of writing [[a recent entry GoReflectEscapeHack]]: > Despite being in a package, _unsafe.Pointer_ is really a built in type > in the Go compiler, just like _map_, _chan_, _string_, and so on. While there is an _unsafe_ package and it looks somewhat superficially like _reflect_ (which is a real package with real code), this is an illusion. All parts of _unsafe_ are implemented at compile time inside the compiler and as part of this _unsafe.Pointer_ is a built in type, much like _uintptr_ (or more to the point, something complex like _chan_, _map_, or slices). One consequence of this is that nothing involving an _unsafe.Pointer_ (such as how it interacts with escape analysis) can be understood or predicted by thinking about it at the Go level through analogies to regular pointers or the like. _unsafe.Pointer_ is not just a little bit magical; it's a *lot* magical. (See eg _TUNSAFEPTR_ in [[go.go https://github.com/golang/go/blob/master/src/cmd/compile/internal/gc/go.go]]. The _unsafe_ functions are interpreted at compile time in [[unsafe.go https://github.com/golang/go/blob/master/src/cmd/compile/internal/gc/unsafe.go]], which turns all of them into literals of type _uintptr_.) I imagine a large reason that _unsafe.Pointer_ is not simply _Pointer_ is so that people are forced to explicitly import _unsafe_ in order to use it. This probably both avoids some casual use and makes it easier to find (or check for) potential dangerous things; all you have to do is scan things looking for imports of _unsafe_. (There's also that '_go tool compile_' accepts a _-u_ argument, which disables use of _unsafe_ as part of its effects.) (Perhaps this has been obvious to other people, but it wasn't to me, especially given that _reflect_ seems to involve at most a tiny little bit of special compiler magic; in Go 1.5, it's a lot of real Go code in a real package.)