Is there the incompatibility risk when using the XxxxPointer functions in sync/atomic package in later go versions?

[T L]

.

[Jan Mercl]

On Wed, Sep 7, 2016 at 4:54 PM T L <tapi...@gmail.com> wrote:

https://golang.org/doc/go1compat

--

-j

[T L]

On Wednesday, September 7, 2016 at 10:56:38 PM UTC+8, Jan Mercl wrote:

On Wed, Sep 7, 2016 at 4:54 PM T L <tapi...@gmail.com> wrote:

https://golang.org/doc/go1compat

yes, risk exists?
 

--

-j

[T L]

On Wednesday, September 7, 2016 at 10:56:38 PM UTC+8, Jan Mercl wrote:

On Wed, Sep 7, 2016 at 4:54 PM T L <tapi...@gmail.com> wrote:

https://golang.org/doc/go1compat

Then how to write compatibility safe atomic pointer reads/writes code? Do I must use atomic.Value for pointers?
 

--

-j

[Ian Lance Taylor]

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.

Ian

[T L]

As the go1compat says unsafe package is not promised to keep compatibility,
so I think atomic.Load/Store/SwapPointer functions are also not promised to keep compatibility, am I right?
 

Ian

[Jakob Borg]

But package sync/atomic is not package unsafe,  so why would you think that?

//jb

[T L]

Aren't the parameters of atomic.Load/Store/SwapPointer functions (*)unsafe.Pointer?
 

//jb

[Jan Mercl]

On Thu, Sep 8, 2016 at 2:51 PM T L <tapi...@gmail.com> wrote:

> Aren't the parameters of atomic.Load/Store/SwapPointer functions (*)unsafe.Pointer?

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.

--

-j

[Henrik Johansson]

Or maybe it works the other way? Because sync/atomic is covered then by accidental extension so is unsafe.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ian Lance Taylor]

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.

Ian

[T L]

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]

Which docs?

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,
further changes.

Ian

[T L]

Ok, got it. Thanks.