On Mon, Feb 26, 2018 at 7:20 PM, <d...@veryhaha.com> wrote: > > On Monday, February 26, 2018 at 2:24:39 PM UTC-5, Ian Lance Taylor wrote: >> >> On Mon, Feb 26, 2018 at 9:42 AM, <di...@veryhaha.com> wrote: >> > >> > On Monday, February 26, 2018 at 12:35:13 PM UTC-5, Jakob Borg wrote: >> >> >> >> On 26 Feb 2018, at 18:21, "di...@veryhaha.com" <di...@veryhaha.com> >> >> wrote: >> >> >> >> On Monday, February 26, 2018 at 11:48:36 AM UTC-5, Jakob Borg wrote: >> >>> >> >>> On 26 Feb 2018, at 16:38, di...@veryhaha.com wrote: >> >>> >> >>> >> >>> Will the "sync/atomic" package get broken? >> >>> This atomic package imports unsafe. >> >>> >> >>> >> >>> If changes to unsafe break sync/atomic it’s up to the Go team to fix >> >>> sync/atomic before releasing. Much like it’s up to other package >> >>> authors to >> >>> make sure their packages work when unsafe changes, if they depend on >> >>> package >> >>> unsafe. You can depend on sync/atomic working. >> >> >> >> Show Quoted Content >> >>> >> >>> On 26 Feb 2018, at 16:38, di...@veryhaha.com wrote: >> >>> >> >>> >> >>> Will the "sync/atomic" package get broken? >> >>> This atomic package imports unsafe. >> >>> >> >>> >> >>> If changes to unsafe break sync/atomic it’s up to the Go team to fix >> >>> sync/atomic before releasing. Much like it’s up to other package >> >>> authors to >> >>> make sure their packages work when unsafe changes, if they depend on >> >>> package >> >>> unsafe. You can depend on sync/atomic working. >> >>> >> >>> On 26 Feb 2018, at 16:38, di...@veryhaha.com wrote: >> >>> >> >>> >> >>> Will the "sync/atomic" package get broken? >> >>> This atomic package imports unsafe. >> >>> >> >>> >> >>> If changes to unsafe break sync/atomic it’s up to the Go team to fix >> >>> sync/atomic before releasing. Much like it’s up to other package >> >>> authors to >> >>> make sure their packages work when unsafe changes, if they depend on >> >>> package >> >>> unsafe. You can depend on sync/atomic working. >> >> >> >> >> >> I mean whether or not the prototypes of the pointer functions in the >> >> atomic packages will change? >> >> >> >> >> >> I think it's a safe bet that unsafe.Pointer will continue to exist. >> >> >> >> //jb >> > >> > >> > But even if it exits, those pointer atomic functions will still become >> > unusable if the unsafe mechanism is not supported any more. >> >> The Go 1 compatibility guarantee, applied to the sync/atomic package, >> ensures that the type unsafe.Pointer will continue to exist for the >> duration of Go 1. >> >> However, the precise details of how unsafe.Pointer may be used are >> permitted to change. And, in fact, they have changed in the past: >> older versions of Go permitted uses of unsafe.Pointer that current >> versions of Go do not permit. > > > ok, I see. > > My current understanding is, > to use the atomic pointer functions, the unsafe package must be imported, > so the uses of the atomic pointer functions may become invalid tomorrow.
I suppose that is one way of looking at it. I would look at it the other way around: as long as unsafe.Pointer is a meaningful type, the sync/atomic unsafe.Pointer functions will work as expected. If the unsafe package ever changes such that it is invalid to use unsafe.Pointer, then the sync/atomic unsafe.Pointer functions will become useless because there is no way to get the values needed to call them in a useful way. 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.
