langref: describe memory model and atomic orders

[tau-dev]

I tried to make this pretty concise because it helps understandability for me, but please point out if you think anything should be expanded or clarified.

[Rexicon226]

I'm not a core member, but I would like to add my two cents. This is a very sensitive topic that requires an extremely rigorous definition, which the cppreference already provides. In my experience, trying to "simplify" the definition creates certain inconsistencies and should be reserved for blog posts and articles, not language references.

[alexrp]

Yeah, I'm not too keen on trying to specify the (frankly very complicated) C++ memory model in the language reference, especially when we don't yet know if Zig will actually keep this memory model for the long term. Even Rust doesn't try to do this.

IMO, what we should do is simply state that Zig currently inherits the LLVM/C++11 memory model, but that this may change before 1.0. For each type of memory ordering, we could link to the relevant LLVM documentation section and cppreference section, and leave it at that.

[tau-dev]

I think the language reference should stand on its own and provide a decent description even for features that are currently implemented by a dependency, particularly as we are gaining backends that do not use the LLVM dependency.

Note that the memory model of C and C++ is significantly more subtle than that of LLVM, so the comparison to cppreference is largely irrelevant. In particular, C/C++ have the notion of consume, which Clang just treats as the simpler acquire. I believe I have not modified the meaning of LLVM's definitions nor omitted important information.

[zxubian]

Not a core member, but here's my 2 cents:

I think that lines 4040~4212 are a concise way of explaining the status quo while providing further references 👍

I'd say that everything below line 4212 is excessive for this PR.

• The text as is attempts to give an introductory overview of motivation behind memory consistency models without rigorously defining any particular one. However, I believe the language reference is not the correct place to learn about memory models in general.
• Attempting to rigorously define the LLVM memory model surely would also be outside the scope of Zig's langref.

So, I'd argue that the best thing Zig can do right now is exactly captured in lines 4040~4212 of this PR: explain the status quo, reference LLVM, and note that things might change.

[tau-dev]

The point of a reference is to describe the language accurately, without saying only "go read the formal specification". Why should this principle not apply to the section on multithreading?

[alexrp]

I think the language reference should stand on its own and provide a decent description even for features that are currently implemented by a dependency

I'm not sure I buy this argument. What about e.g. floating point semantics? Where would we draw the line?

I think it's fine to reference a third-party spec when the Zig language is just providing an implementation of that spec, as opposed to actually defining it authoritatively.

[tau-dev]

The cppreference, the Rust std docs and the Nomicon describe the memory model but not IEEE754 floats.

IEEE754 has become a de-facto standard for most high- and low-level programming languages in use today, while the majority of languages out there do not expose a memory model of "just what LLVM does".

Also note that the language reference isn't defining anything authoritatively. That will be the job of the specification, which will define the memory model formally—or defer to LLVM—for implementers and tool authors. The reference should give common users a precise but fast-to-acquire understanding of the language, and I believe LLVM's specification is too formal and scattered to do that.