Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: Go 2: sync/atomic: type modifiers as an addition to types #29501

tema3210 opened this issue Jan 2, 2019 · 4 comments

proposal: Go 2: sync/atomic: type modifiers as an addition to types #29501

tema3210 opened this issue Jan 2, 2019 · 4 comments


Copy link

@tema3210 tema3210 commented Jan 2, 2019


For example:
All of us seen golang's Atomic package. It's quite unnatural way of defining atomic vars isn't it?

My proposal is to introduce type prefixes subsystem.In another words: make simple,readable way for making data atomic, shared, imutable, etc


--Golang today:

var t int64

--With descibed feature:

var t atomic int64 //now all operations with t will be atomic.

Ofcourse, there are several issues:
1)Loosing opportunity to modify variable in non-atomic way
2)(much) Increasing internal compiler complexity

-For the first one, cure is to use & operator which should has *int64 return type, not atomic *int64 nor
*(atomic int64). It would be nice, because force changing variable which is atomic indicates issuses in architecture.
(see EDIT)

-For the second one, my proposal is to make a kind of system, that describes variable in much abstract way, in order to allow inserting custom code before and after any kind of operation with variable. In another words: make Pre-acess and Post-acess parts in data operation model, used in code generation process. I think it won't be much penalty, because such thing will allow future modifications in that way to be easier to implement.

For swap and compare-and-swap there is still Atomic package.

P.S Another such modifiers I would like to see are "const" and "binary serialisable"(loading from []byte exactly in ram)(hello protobuf!). You are welcome to suggest your ones.


I see my mistake, the & operator really should have *(atomic int64) return type (adress of atomic , not content) ,and it won't be a cure.

@katiehockman katiehockman changed the title type modifiers as an addition to types sync/atomic: type modifiers as an addition to types Jan 2, 2019
Copy link

@katiehockman katiehockman commented Jan 2, 2019

@ianlancetaylor ianlancetaylor changed the title sync/atomic: type modifiers as an addition to types proposal: Go 2: sync/atomic: type modifiers as an addition to types Jan 3, 2019
@gopherbot gopherbot added this to the Proposal milestone Jan 3, 2019
Copy link

@ianlancetaylor ianlancetaylor commented Jan 4, 2019

I don't really understand how this is supposed to work if the address of a atomic int64 is a plain *int64. That means that the behavior of the variable changes depending on whether you assign to it directly or whether you take the address and assign via the pointer. That sounds very confusing and error-prone.

Copy link

@deanveloper deanveloper commented Jan 6, 2019

From sync/atomic package-level docs:

These functions require great care to be used correctly. Except for special, low-level applications, synchronization is better done with channels or the facilities of the sync package. Share memory by communicating; don't communicate by sharing memory.

Seeing that the use of sync/atomic is discouraged (since it doesn't align well with Go's concurrency paradigm), it's probably not a good idea to add a language feature that encourages it's use.

@golang golang deleted a comment from Davidc2525 Jan 18, 2019
Copy link

@bcmills bcmills commented May 13, 2019

See previously the #Atomic capability proposed in #24956.

Type modifiers do not seem particularly useful unless they can be tracked across function calls and through pointers and other data structures, and the details of making that tracking work quickly become so verbose as to not fit in with the rest of the design of Go.

(Note that I withdrew that proposal for that reason in #24956 (comment).)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants