Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
ianlancetaylor opened this issue Jun 26, 2018 · 3 comments

Comments

@ianlancetaylor
Copy link
Contributor

commented Jun 26, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Jun 26, 2018

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

@robpike

This comment has been minimized.

Copy link
Contributor

commented Jun 26, 2018

I like this one.

@bcmills

This comment has been minimized.

Copy link
Member

commented Jun 26, 2018

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.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.