11–20 of 31 posts
I can see how multiple mutable references is fine in a single-threaded context, but surely this would cause UB in the multi-thread context?
I can see how multiple mutable references is fine in a single-threaded context, but surely this would cause UB in the multi-thread context?
Given their "shape stability" design, not necessarily. The three ways that multithreaded access can cause UB are: * changing the type of the underlying memory (e.g. because it's part of an enum variant and you changed the tag, or because you changed the length of a vector) * data races (can be defined away by making [effectively] every access Relaxed, as Java does * use after free (resolved here by reference counting…
What is "stable shape"?
>"I have to admit, this is beautiful" Terse it is, beautiful it is not (well my version of beautiful that is - easy to read and understand). this is not to diminish the language.
What is "stable shape"?
Creator of Ante here. It's just a term I made up for mutation which does not change the "shape" of data in a way that can invalidate any of that data. Mutating a struct or tuple field, even if nested, is stable for example, but mutating an optional string to None is not because you may be dropping a string which there may be a reference to somewhere.
What about Vale? Is this a rename of it or something new?
Hi, article's author here (Verdagon, Vale's creator), and no, I'm just writing about someone else's language (Ante) that I thought was interesting. Ante is making some very intriguing steps forward in memory safety design and I thought others would find it interesting too.
I doubt it can work in multithreaded code. Allowing sharing mutable references (even to simple structs) means race conditions, temporal inconsistency between different struct fields and even incorrect read results for basic integer types (if the target CPU can't atomically read/write values of types like u64).
In my programming language I generally don't allow having more than one mutable reference to a variable. The only exception is when two references point to different elements of structs/tuples. This gives some flexibility without sacrificing correctness.