On Monday, February 26, 2018 at 11:21:43 PM UTC-5, Ian Lance Taylor wrote: > > On Mon, Feb 26, 2018 at 7:20 PM, <di...@veryhaha.com <javascript:>> > 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. >
ok, this is really make gophers worry about whether or not the pointer atomic functions should be used. > > 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.
