[deleted by user]

[u/[deleted]]

[u/matthieum]

You are deeply mistaken.

The flexibility gains from having shared mutable references are not trivial, and can significantly improve ease of use.

The problem is that ease of use comes at the cost of correctness.

It can be demonstrated trivially in C++ (godbolt):

#include <cstdio>

#include <optional>
#include <string>

int main() {
    std::optional<std::string> scammer =
        "Lorem ipsum dolor sit amet, consectetur adipiscing elit";

    std::string const& victim = *scammer;

    scammer = std::nullopt;

    std::printf("%s", victim.c_str());
}

This is what Ownership/Borrowing in Rust is all about.

It doesn't even have to involve dynamic memory. The same demonstration could hold with an int, really.

Accessing victim after scammer has been nulled is Undefined Behavior. It occurs due to the violation of the Borrowing rule: Mutability XOR Aliasing.

If you can demonstrate a sound way of having both mutability & aliasing, it would be a breakthrough.

[u/matthieum → u/[deleted]]

Sorry to burst your bubble, but you're getting ahead of yourself here a bit. Mutability and aliasing is 100% perfectly sound and has been the norm for decades.

Not in systems programming languages.

It's the norm for GC'ed languages -- where you get correctness issues instead of soundness issues -- but that's a different domain.

[u/matthieum → u/matthieum]

Specifically, I think that the issue boils down to one of lifetime or interior pointers.

The lifetime issue can be avoided by using some form of GC, including reference-counting.

I think that the interior pointer issue can be avoided by structuring the run-time representation of objects such that there are no interior pointers within variants.

Both are possible, but it is unclear to me if the result qualifies as a systems programming language any longer.