Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
proposal: Go 2: only give special properties to unsafe.Pointer if package imports unsafe #26070
One of the difficulties of
For Go 2 I propose that we change the language to say that values of type
If we make that change, then, Go 1 compatibility rules aside, we can safely permit
Under this proposal, in order to determine whether a conversion expression
(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.
(I do agree that this proposal is a strict improvement over the status quo, but in the space of “fixes for
I don't find this argument compelling. I think we can safely permit reflect.Value.Pointer to return unsafe.Pointer today anyway (again, Go 1 compatibility rules aside).
The Go toolchain no longer supports "safe" mode, so there's no builtin functionality that restricts access to package unsafe. So this argument is implicitly assuming some external safety-validation tool that restricts access to package unsafe.
But then I don't see any reason such an external tool can't just look for
I think a security-oriented subset of Go a la Joe-E or Caja would be fun to work on, but I don't think trying to one-off tackle individual issues is going to get us there. (I also suspect compiling to wasm is a more pragmatic solution to this problem.)
That said, we already tie other unsafe features like
So overall I'd say I'm weakly opposed.