# Would the new atomic break the generic code?

**URL:** <https://discourse.julialang.org/t/would-the-new-atomic-break-the-generic-code/100627>\
**Category:** General Usage\
**Created:** [June 20, 2023, 10:23pm UTC](https://discourse.julialang.org/t/would-the-new-atomic-break-the-generic-code/100627 "2023-06-20T22:23:20Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Tarny\_GG\_Channie](https://avatars.discourse-cdn.com/v4/letter/t/3bc359/32.png) [@Tarny\_GG\_Channie](https://discourse.julialang.org/u/Tarny_GG_Channie)\
**Post date:** [June 20, 2023, 10:23pm UTC](https://discourse.julialang.org/t/would-the-new-atomic-break-the-generic-code/100627/1 "2023-06-20T22:23:20Z")

</div>

This comes from the [Julia Atomics Manifesto](https://gist.github.com/vtjnash/11b0031f2e2a66c9c24d33e810b34ec0)

Strictly, it is not a “breaking” change, because it would work on the old code just fine. However, the problem is with the atomic fields.  
Let’s say

```julia
struct A
    @atomic B::Int
end

function do_something(x)
    x.B += 1
end

```

do\_something now won’t work for everything with the B field.  
Now, you could use getters and setters, but how would that work with atomic?  
Now do we have to write

```julia
function do_something(x)
    @atomic :not_atomic x.B += 1
end

```

for everything?  
Maybe we could automatically upgrade the non-atomic writes too? But… issues, issues, issues?  
Maybe you would not declare atomic any general-purpose data anyway so it might work.

---

<div class="post-metadata">

**Author:** ![jpsamaroo](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jpsamaroo/32/46804_2.png) [@jpsamaroo](https://discourse.julialang.org/u/jpsamaroo)\
**Post date:** [June 22, 2023, 1:53pm UTC](https://discourse.julialang.org/t/would-the-new-atomic-break-the-generic-code/100627/2 "2023-06-22T13:53:22Z")

</div>

Not all code can be made composable, and code which accesses struct internals is usually not expected to be (as we don’t have inheritance of struct fields). Instead, it’s usually expected that composability happens via multiple dispatch, so choosing behavior based on the _type_ of the struct, instead of the _contents_ and _layout_ of the object.

Upgrading non-atomic writes doesn’t necessarily do the right thing, you really need to write your accesses in a manner which is fully aware of the fact that you’re accessing an atomic field.