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, <[email protected] <javascript:>> > wrote: > > > > On Monday, February 26, 2018 at 12:35:13 PM UTC-5, Jakob Borg wrote: > >> > >> On 26 Feb 2018, at 18:21, "[email protected]" <[email protected]> > wrote: > >> > >> On Monday, February 26, 2018 at 11:48:36 AM UTC-5, Jakob Borg wrote: > >>> > >>> On 26 Feb 2018, at 16:38, [email protected] 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, [email protected] 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, [email protected] 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
