MVS idiomatic reference replacements

[Sebastian7862]

It would be good to have a list of how to replace references and pointers in situations, when those are used in C++.

One example where a solution was provided is the graph by replacing pointers with lists of indices together with the parent object.

Another example are iterators, where there are also solutions with indices or subscripts.

How would one do it for situations, which currently rely on ownership semantics. We are in a member function (method). The struct we need to write-access is stored in an outer struct (which also contains the object, for which the member function is called, so I am talking about an uncle-nephew relationship of the parts) as separate part. We know that that outer struct is alive as it outlives us (us=the struct the member function is called for). In C++ probably our constructor would receive a (non-owning) reference to that outer struct and we would store it as member variable.

Perhaps for those kind of hierarchical ownership guarantees, there would have to be a separate mechanism. Like: An object always has full access to all its encompassing objects? But in that generality that would open up possible aliases.

Or member functions would (in those cases) need the outer struct as separate parameter. That would feel a lot like global variables and those outer structs can be used (mutatingly) only once at the same time, so one would have to specify the actual sub-object (the uncle from the grandmother). Would each member function caller have to do this for each call?

——————

Another use case is a struct, which several threads want to access from time to time. We want to block, if it is currently not available. So we would need a handle and a function to call returning the object and another function for releasing it?

There are surely other cases, but would be nice to solve those two.

[kyouko-taiga]

I'm not sure I understood your use case, but here's how I pictured it.

type A {
  public memberwise init
  public var mother: {me: B, sister: Int}
  public var uncle: Int
  public fun bar() inout {
    &mother.me.foo(&uncle)
  }
}

type B {
  public init() { &self.x = 1 }
  public var x: Int
  public fun foo(inout uncle: Int) inout {
    &uncle += x
    &x = uncle.copy()
  }
}

public fun main() {
  var grandmother = A(mother: (me: B(), sister: 0), uncle: 1)
  &grandmother.bar()
}

Generally, if you shape all your data structure like trees, you can always mutate anything you like from a root using inout.

For concurrent access across threads you'll need run-time support. Val requires access to be known unique statically but it also offers an escape hatch to express safe APIs using unsafe constructs guarded by the necessary run-time checks.

That said, concurrency is a tricky domain. Once you lose local reasoning it becomes difficult to make sense of your program, even if you have safety. Value semantics will keep you out of data races but won't address other race conditions. My personal opinion is that threads should probably be banned from the user model in general, just like pointers and references. There are other ways to do concurrency.

[dabrahams]

IIUC the OP is actually asking about how to do it in C++?

[kyouko-taiga]

Oh, I see. I guess you can discipline yourself to use T& just like you'd use inout in Val.

But I know almost nothing about C++, so I'll let more competent people answer if that was indeed OP's question.

[dabrahams]

@Sebastian7862 are you asking about C++?

[Sebastian7862]

@kyouko-taiga Thank you for your answer
@dabrahams I was asking about how to do a typical C++ usage of references, where the lifetime guarantee is easy to see, now or in the future in val.

To better express, what I meant, I will give you a concrete code example below in C++ to explain.

[The father/mother generation was unnecessary, I left it away, but kept the type names (grandmother e.g.).]

In this example, nephew needs an object of utility type. In this example, the utility object counts calls to certain functions.
We have a guarantee (by grandmother and her order of member variables), that uncle always outlives neph.

From a C++ perspective this would be totally fine and safe.
From a val perspective there would be two access paths to uncle.

In val dosomething() would probably need an inout parameter providing gm or gm.uncle each time it is called.
Due to aliasing it would not be possible to provide both a mutable gm and gm.neph (as this=self parameter), so the calls would have to be gm.neph.dosomething(gm.uncle).
The whole fixed association between the uncle and the nephew would have to be repeated with each call.
Including the exact path from gm to the uncle instead of initializing this once or coding it into one of the structs.

This case is a simple example. Single thread. One object comprising two parts. utility_uncle does not call other user functions (it calls a system function for printing) and the main function has full mutable access to the whole grandmother.

However, safety can only be reasoned by looking at grandmother. She ensures it by her layout (uncle before=around nephew) and by C++ lifetime rules.

Is there an idiomatic way to program this association between nephew and uncle in val?

Otherwise val has perhaps less expressiveness for certain kinds of tasks.
Then it could make sense to enrich MVS with a second kind of mechanism, which also guarantees safety, even if it would be a separate category of variables/types.

As the association between uncle and neph is an invariant during the life of grandmother, perhaps this association could be re-executed/confirmed for each member function call like dosomething(). To make the association hard-coded in the type grandmother, but temporary from a MVS perspective.

Example program:

#include <iostream>

// e.g. store, how often certain functions were called
struct utility_uncle {
    void increase() { internalvar++; };
    void print() { std::cout << internalvar << std::endl; };

    int internalvar = 0;
};

// nephew needs an associated utility_uncle
struct nephew {
    // : notation initializes member variables before entering the constructor, necessary for references, which cannot be reassigned later
    nephew(utility_uncle& util) : storedutil(util) {};
    void dosomething() { storedutil.increase(); }

    utility_uncle& storedutil;
};

// by the order of the member variables, the uncle is constructed first and destructed last
// we have a guarantee that uncle outlives neph
struct grandmother {
    grandmother() : neph(uncle) {};

    utility_uncle uncle;
    nephew neph;
};

int main() {
    grandmother gm;
    gm.uncle.print(); // prints 0
    gm.neph.dosomething();
    gm.uncle.print(); // prints 1
}

-> https://godbolt.org/z/qT4jhccPe

To better test a solution, the tasks could be made one step more complicated, by having more than one nephew all being associated with the same uncle.

Or by having nephews and uncles being dynamically added and removed instead of being fixed fields = member variables.

[kyouko-taiga]

Indeed, you can't express that program in the safe subset of Val.

The problem is not memory safety here. Your example doesn't adhere to the principles of mutable value semantics because it violates the independence of the values in your program. You cannot reason locally about the behavior (not only lifetime) of uncle because mutating other, seemingly unrelated objects may cause a mutation (a.k.a. spooky action at a distance).

Mutable value semantics is more about local reasoning than it is specifically about safety. The significant overlap between the two concepts is due to the fact that most (if not all) sound and computationally reasonable approaches to guarantee safety require local reasoning.

If you must, you could use unsafe pointers to safely share mutable objects. Val has an escape hatch from its static checks which lets you use pointers. It's reasonable to want to share mutable objects if we can reason about their lifetimes and behaviors. In those cases, though, the compiler will generally be unable to prove safety for you.