We can divide our program's memory into regions, for safer and faster code.
(These are planned features, see the roadmap for plans!)
Every function has its current region, but can access other regions as well.
We often call main's region the main region.
A common pattern is for a function to regard all of its parameters as coming from a read-only region.
Notice the <'a ro>. The ' means region, followed by its name (a), followed by its permission (ro which means read-only).
When main passes in allShips from the main region into the 'a &List<Ship> parameter, biggestShipName:
This locks down the entire main region. Nobody can modify it.
Because of this, the compiler is free to do much more powerful optimizations. 0
The compiler also keeps track of all references' regions, and makes sure that no reference outlive their region.
A mutex is a special wrapper around a region that can be opened by someone for reading and writing, or opened by multiple people for only reading.
We can make a mutexed region with the Mutex function.
It accepts a regioned object. A regioned object is an object where all of its (directly or indirectly) owned objects refer only to each other and are referred to only by each other.
Here, we're making an regioned object with a region call, the 'a makeGame().
Mutex will take the regioned object, and wrap it in a Mutex object.
We can open the mutex for reading via its rlock method, which will return a RLock object, which contains a read-only reference to our regioned object.
There's a corresponding rwlock method for read-write access.
The compiler keeps track of all references' regions, and makes sure that no references outlive their lock.
One region cannot "open" another to gain access to it. Rather, we make a new region that has access to them both.
Even in the above example, when we opened the mutex (using rlock or rwlock, we were creating a temporary new region.
Making constraint references and weak references into read-only regions are completely free; the compiler optimizes them into raw pointers.
We can move an object to another region by putting the destination region's lifetime annotation ('a) in front of the data.
We call this transmigrating.
Here we're transmigrating a Drawable from region 'a to region 'b.
Notice how we put the destination region 'b in front of the object baseInA.
Transmigrating has a cost though: Vale must turn the object into a regioned object first!
To turn an object into a regioned object, it must secede, which means it must sever any references between things it indirectly owns ("descendants"), and everything outside ("outsiders").
This can be costly. 1
Luckily, we can avoid this cost!
The cost depends on various factors:
There are three ways to avoid secede costs:
To illustrate that last point, we can change segmentify.
Notice how segmentify now accepts its parameter from a different region 'a.
Because of this, segmentify gets its own region. It's making its Vec2s and Drawable in this new region.
Because the return isn't 'a, the compiler knows that Drawable is a regioned object.
Now, segmentifyAndSend doesn't cause a secede!
With the bump keyword on a region declaration, all the region's allocations will use a bump allocator. This is especially useful for calling pure functions which have short lifetimes. 2
Regions are useful in many situations:
More explanation soon, stay tuned or swing by our discord for more information!