Daniel Urban

Huh, yeah, that makes sense. Basically, even if we'd make `Ref` useless, it wouldn't be _completely_ useless :smile:

So I've skimmed the "All Fields are Final" article again, and the cost doesn't seem so dramatic to me. The conclusion seems to be that on x86 it is practically...

> If I understand correctly, I wouldn't describe this as avoiding the acquire fence. Rather, there is semantically an acquire there, that just happens to require emitting no instructions on...

> In our case, speculation is ok: because finalField is final, any values obtained by speculation prior to the load must be consistent with the value after the load. I...

> 2. store instances with relaxed ordering Doesn't scala-native need this _anyway_? For _every_ access to shared memory, since data races are undefined behavior (on LLVM).

Ah, okay. And that's not enough for the situation with `final`s? Does it really need _monotonic_ (which is apparently the same as _relaxed_)?

We're getting very much offtopic here, but... > If anything, they seem to [say the opposite](https://mariadb.org/wp-content/uploads/2017/11/2017-11-Memory-barriers.pdf) i.e. that it won't work Yeah. Except that's C++; what "we" (i.e., scala-native, really...

At this point, I think I'll just say that _atomic_ is whatever the spec says is _atomic_; and if another part of the spec (e.g., the `fence` instruction) requires _atomic_,...

Returning to CE a little bit... > if it is impossible to efficiently implement final Field Semantics on Scala Native (...) then we should be more aggressive about designing and...

> It might be helpful to talk about some specific examples Yeah, you're right: 1. The one you linked (`_join`): this is a good example; however, `volatile` is stronger than...