proposal: Go 2: only give special properties to unsafe.Pointer if package imports unsafe

[ianlancetaylor]

One of the difficulties of unsafe.Pointer is that if a package gets a value of type unsafe.Pointer then it can convert that pointer to other pointer types, or uintptr. This is true even if the package does not itself import "unsafe", but gets the unsafe.Pointer value by calling some other package. This is the reason that reflect.Value.Pointer returns uintptr rather than unsafe.Pointer.

For Go 2 I propose that we change the language to say that values of type unsafe.Pointer only have their special properties in packages that explicitly import "unsafe". If a package does not import "unsafe", then a value of type unsafe.Pointer may not be converted to other type.

If we make that change, then, Go 1 compatibility rules aside, we can safely permit reflect.Value.Pointer to return unsafe.Pointer.

[randall77]

Presumably this will also let us redefine reflect.StringHeader and reflect.SliceHeader to use unsafe.Pointer instead of uintptr.

[randall77]

Presumably this will also let us redefine reflect.StringHeader and reflect.SliceHeader to use unsafe.Pointer instead of uintptr.

[robpike]

I like this one.

[robpike]

I like this one.

[bcmills]

Under this proposal, in order to determine whether a conversion expression T(x) may be an unsafe.Pointer conversion, the reader still needs to know three things that may not be locally obvious:

1. whether the operand is a pointer or uintptr type,
2. whether T is an alias for unsafe.Pointer, and
3. whether the current source file has imported package unsafe.

(1) and (2) may be arbitrarily distant in the code (even across package boundaries); (3) is fairly easy to find within the source file, but still requires the reader to jump from the current context to the import block and back.

In contrast, with a function-based unsafe API (such as the one @griesemer and I discussed in #20171), I believe all of that information could be present within the conversion expression itself.

(I do agree that this proposal is a strict improvement over the status quo, but in the space of “fixes for unsafe.Pointer” it seems like the low-cost/low-benefit solution. I wonder whether we could get a much larger benefit for an only marginally higher cost.)

[bcmills]

Under this proposal, in order to determine whether a conversion expression T(x) may be an unsafe.Pointer conversion, the reader still needs to know three things that may not be locally obvious:

1. whether the operand is a pointer or uintptr type,
2. whether T is an alias for unsafe.Pointer, and
3. whether the current source file has imported package unsafe.

(1) and (2) may be arbitrarily distant in the code (even across package boundaries); (3) is fairly easy to find within the source file, but still requires the reader to jump from the current context to the import block and back.

In contrast, with a function-based unsafe API (such as the one @griesemer and I discussed in #20171), I believe all of that information could be present within the conversion expression itself.

(I do agree that this proposal is a strict improvement over the status quo, but in the space of “fixes for unsafe.Pointer” it seems like the low-cost/low-benefit solution. I wonder whether we could get a much larger benefit for an only marginally higher cost.)