On Thu, Sep 8, 2016 at 8:16 AM, T L <tapir....@gmail.com> wrote: > > On Thursday, September 8, 2016 at 10:50:36 PM UTC+8, Ian Lance Taylor wrote: >> >> On Thu, Sep 8, 2016 at 3:46 AM, T L <tapi...@gmail.com> wrote: >> > >> > On Thursday, September 8, 2016 at 12:33:37 AM UTC+8, Ian Lance Taylor >> > wrote: >> >> >> >> On Wed, Sep 7, 2016 at 8:16 AM, T L <tapi...@gmail.com> wrote: >> >> > >> >> > 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? >> >> >> >> 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. >> > >> > >> > 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? >> >> 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 > > > Thanks for the confirmation. > > It would be clearer to write down "unsafe package and unsafe.Pointer will be > there for ever" in docs.
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 -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
