|Is there the incompatibility risk when using the XxxxPointer functions in sync/atomic package in later go versions?||T L||9/7/16 7:53 AM|
|Re: [go-nuts] Is there the incompatibility risk when using the XxxxPointer functions in sync/atomic package in later go versions?||Jan Mercl||9/7/16 7:56 AM|
|Re: [go-nuts] Is there the incompatibility risk when using the XxxxPointer functions in sync/atomic package in later go versions?||T L||9/7/16 7:59 AM|
|Re: [go-nuts] Is there the incompatibility risk when using the XxxxPointer functions in sync/atomic package in later go versions?||T L||9/7/16 8:16 AM|
|Ian Lance Taylor||9/7/16 9:33 AM|
Perhaps you could explain what kind of compatibility risk you are
concerned about that is not covered by the Go 1 compatibility
guarantee. Please give an example of code that will work today but
that you think may stop working in future releases. Thanks.
|T L||9/8/16 3:46 AM|
|Jakob Borg||9/8/16 4:00 AM|
But package sync/atomic is not package unsafe, so why would you think that?
|T L||9/8/16 5:50 AM|
Aren't the parameters of atomic.Load/Store/SwapPointer functions (*)unsafe.Pointer?
|Jan Mercl||9/8/16 6:01 AM|
On Thu, Sep 8, 2016 at 2:51 PM T L <tapi...@gmail.com> wrote:
Yes, they are. Using any package API that involves unsafe.Pointer implies your program must "import unsafe" to use it. And that means your program is not covered by the Go compatibility promise. TBH, I did not realize that before. But don't panic yet! Backward incompatible changes to package unsafe are not common, nor very likely in the future, even though recently-ish the rules for messing with unsafe.Pointer actually were changed, IIRC.
|Henrik Johansson||9/8/16 6:08 AM|
Or maybe it works the other way? Because sync/atomic is covered then by accidental extension so is unsafe.
|Ian Lance Taylor||9/8/16 7:50 AM|
No. The Go 1 compatibility document doesn't say that anything about
the unsafe package can change. It says that packages that use unsafe
"may depend on internal properties of the Go implementation." That is
not intended to mean that such packages depend on internal properties
merely because they import unsafe. It is intended to mean that
packages that import unsafe may then (perhaps accidentally) use the
unsafe values in ways that depend on internal properties. The
atomic.Load/Store/SwapPointer functions don't use the unsafe values in
any way at all. They just move the values around. That is always
going to be OK.
Even if it somehow wasn't, the Go 1 compatibility guarantee does cover
the sync/atomic package. That package is guaranteed to remain
compatible, so atomic.Load/Store/SwapPointer will continue to work as
they do today, even if the unsafe package somehow, unimaginably,
changes so that they don't.
|T L||9/8/16 8:16 AM|
Thanks for the confirmation.
It would be clearer to write down "unsafe package and unsafe.Pointer will be there for ever" in docs.
|Ian Lance Taylor||9/8/16 9:10 AM|
I think the Go 1 compatibility doc is currently accurate. We reserve
the right to make changes to the implementation of the unsafe package.
Not to the API, but to the implementation. That is, the unsafe
package and unsafe.Pointer are guaranteed to remain, but it is
possible that certain aspects of their implementation will change.
That said, for the 1.6 release we clarified when unsafe.Pointer may be
used safely, and there are no current plans for, or expectations of,
|T L||9/8/16 9:29 AM|
Ok, got it. Thanks.