Would the new atomic break the generic code?

General Usage
1

This comes from the Julia Atomics Manifesto

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

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

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.

2

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.

2 Likes