Reference mutability and locking mechanisms

[benStre]

Reference mutability is still not completely solved.
We currently distinguish between & (immutable references) and &mut (mutable references).
This is similar to Rust, but not quite, because we still allow multiple mutable and immutable references to exist at the same time.

Since immutable references can always be derived from mutable references, we cannot guarantee that an immutable reference is not mutated by someone else while we are working with it. This leads to very non-deterministic behavior which we must definitely to avoid.

One useful concept would be to introduce some sort of &final immutable reference that is guaranteed to be completely static and cannot be mutated by anyone. This can e.g. be useful for type definitions that should always be final to get predictable (compile-time) behavior.

But for normal references, the problem still exists.
Example:

function doStuffWithObject(obj: &MyObject) (
  // ...
  if obj.someProperty matches integer (
     // the compiler asserts that the type of obj.someProperty is integer throughout this whole block
     obj.someProperty * 2; // allowed
     // ...
     // after doing some other stuff, someone else might have changed obj.someProperty to "xyz"
     obj.someProperty * 2; // !! compiler still thinks this is allowed, but obj.someProperty is actually "xyz", leading to an unexpected runtime error
  )
)

A possible approach to fix this would be to restrict reference access like Rust, allowing only one mutable reference OR multiple immutable references to be used at the same time. We would need some sort of locking mechanism that locks a mutable reference at the beginning of a scope and unlocks it at the end.

But this can lead to unexpected dead locks. It might also be inefficient to do this every time for any reference access.

Lets create an example scenario: We have one endpoint that regularly updates a reference, e.g. a counter, and 1000 subscriber endpoints that observe the reference and do some formatting on the counter value before displaying it reactively. We must now always ensure that while the origin endpoint updates the reference, all other endpoints don't access the reference. Afterwards, they can all run the formatting on the (immutable) reference and display the new value. For this simple scenario, we actually wouldn't need and locking mechanism, since the subscriber endpoints only access the reference after the origin has mutated it and informed the subscribers, triggering an observer event afterwards.

But for multiple endpoints that mutate a pointer, this can get much more complex.
We should probably construct some example scenarios and think about how we would handle them regarding reference mutation and locking.

@jonasstrehle @janiejestemja @TeeB3utel

[jonasstrehle]

Are functions refs or values?

• We need refs vor recursion, usage(references of other declared functions in bodies