My recollection is that one of the reasons that Value.Pointer returns uintptr is that we wanted to prevent code like

p := v.Pointer()

from giving p the type unsafe.Pointer in a package that does not import unsafe. Of course you can do this already using your own packages, but we didn't want to encourage it in the standard library.

(This also gets us to a discussion about type based alias analysis. In ordinary Go code a pointer to *byte and a pointer to *int must always point to different locations, so changing memory through one pointer can't affect memory changed through the other pointer. But that statement is no longer true if either value was set via a conversion through unsafe.Pointer. Does this mean that the compiler can never assume that they point to different locations, or can we say that that assumption changes based on whether the package imports unsafe?)

Re type-based alias analysis: even if the package does not import unsafe we can only assume that variables do not alias if they were allocated from within the package. (A caller can always supply pre-punned pointers as arguments.)

So I think if we want to do any deep reasoning about aliasing we would generally need whole-program analysis either way.

My recollection is that one of the reasons that Value.Pointer returns uintptr is that we wanted to prevent code like p := v.Pointer() from giving p the type unsafe.Pointer in a package that does not import unsafe.

Yes, that reason was justifiable back when Go supported "safe" mode, but we removed that back in 2018. There are many better ways to run untrusted Go programs today (e.g., within a process sandbox like gVisor or by compiling them to wasm).

This also gets us to a discussion about type based alias analysis.

This seems like an orthogonal concern to me. The only way to safely use reflect.Value.Pointer and reflect.Value.UnsafeAddr as pointer values today is to immediately convert them to unsafe.Pointer anyway.

It's somewhat orthogonal but perhaps not entirely negligible: see #26070.

I don't see any mention of type-based alias analysis in #26070. Can you elaborate on how they're related?

The connection I see here is what should happen when people write p := v.UnsafePointer() in a package that doesn't import unsafe, if we adopt #26070. Will it be confusing that they can use := to get an unsafe.Pointer that they can't use?

Perhaps this concern is not important.

I see. I wrote "This seems like an orthogonal concern to me," with "this" referring to type-based alias analysis. When you wrote "It's somewhat orthogonal," I thought you were still talking about type-based alias analysis too.

Assuming both #26070 and this proposal were accepted, I expect users would adapt by writing import _ "unsafe" // for unsafe.Pointer conversion analogous to how they write import _ "unsafe" // for go:linkname today. (Though as I've commented on #26070, I disagree with that proposal.)

#26070 was retracted.
As I remember it, we were picky about importing "unsafe" to get an unsafe.Pointer (and not providing ways to get one otherwise) for two reasons:

1. It's good practice to call out the unsafe parts of the code clearly, and the import does that.
2. App Engine needed to be kept from using unsafe.

(2) is no longer a concern, and (1) seems well enough handled by the name v.UnsafePointer, which seems just as clearly "unsafe" as import "unsafe".

So overall this seems like a fine change. It might be worth thinking about for Go 1.17 along with the other unsafe/pointer cleanup.

Based on the discussion above, this seems like a likely accept (for Go 1.17).

No change in consensus, so accepted.

Replacing v.UnsafeAddr() with v.Addr().UnsafePointer() has a slight added cost v.UnsafeAddr() was able to simply directly return the address pointer, while Addr() potentially has to compute the resulting pointer's type. However, (*rtype).ptrTo already uses caching, and the compiler also already eagerly generates *T types for most types, so I expect in practice this to have negligible overhead.

I'm not so sure about this. I've spent some time optimising a reflect based encoder. Starting with a per-field loop

for _, f := range fields {
    f.codec.encode(writer, v.Field(f.index)) 
}

I ended up with 22% of CPU time on a moderately simple benchmark spent in Value.Field

I decided to try and optimize it using (as a first pass) Value.UnsafeAddr() and reflect.NewAt(t, p)

p := unsafe.Pointer(v.UnsafeAddr())
for _, f := range fields {
    f.codec.encode(writer, reflect.NewAt(f.ty, unsafe.Pointer(uintptr(p) + f.offset)).Elem()) 
}

The result was... 33% of CPU time being spent in reflect.NewAt (and another 11% in Value.Elem()). This CPU time is all spent in ptrTo/typeOff (and it only gets worse in cases where we fall off of that path into the sync.Map cache)

This is probably not a big deal in the grand scheme of things; the overhead is only really notable because I've spent a bunch of effort optimizing other aspects (and I have ways of working around it in the general case), and there's still optimizations which can be done to avoid the reflect overhead in many cases, but it makes these kinds of optimizations a bit trickier (in that you're more likely to bump into situations where you've accidentally made things slower)

So if I were to make a couple of requests, they'd be:

1. An equivalent of UnsafeAddr, and
2. An inverse, i.e. a function equivalent to reflect.NewAt(t, p).Elem() (failing that: a variant of reflect.NewAt where the type parameter is already the pointer?)

Change https://golang.org/cl/350691 mentions this issue: reflect: add Value.UnsafePointer

Change https://golang.org/cl/356252 mentions this issue: reflect: add test that method values have the same code pointers

Change https://golang.org/cl/356255 mentions this issue: doc: document new reflect.UnsafePointer function

Change https://golang.org/cl/360855 mentions this issue: encoding/json: use reflect.Value.UnsafePointer over Pointer