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 <javascript:>> > 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. > > 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.
