The site sections are under development.
The materials may be incomplete or contain errors. The site content will be synchronized with the implementation in the next release, while the current version (0.6.0) is intended for syntax prototyping and for creating the playground.
Memory management and shared access
No single memory management approach is the best or universal: different approaches win under different conditions:
- Manual memory management can do anything, except one thing — guarantee the absence of errors.
- Ownership and borrowing analysis at compile time makes it possible to prove the correctness of code without additional runtime checks, but some scenarios and algorithms cannot be proven statically at compile time.
- Counting strong and weak references at runtime is convenient for shared ownership, but has a non-zero cost and does not protect against cyclic and cross dependencies.
- Garbage collection simplifies working with complex cyclic structures, but has the most expensive overhead and non-deterministic execution.
- None of the listed memory management approaches includes the issues of inter-thread memory access synchronization.
Therefore, choosing only one memory management approach in a programming language means deliberately limiting its capabilities and adding unnecessary overhead. For these reasons, the memory management concept of TrustLang allows extending the implementation of the memory management model with minimal impact on the language syntax and is defined by the requirements (guarantees) for working with memory.
Memory management model
- The language semantics divides variables not by the method of internal implementation, but by semantics, i.e. a variable by value may store data in the heap, but when copying, a copy of all its data located in the heap must also be created.
- A complete description of an object’s lifetime always includes several orthogonal axes and no abbreviated symbolic notation can in principle encode the whole set of combinations (reference kind, access, region membership (lifetime), presence of a destructor for the object, etc.). Therefore, the abbreviated symbolic notation of variable types is intended only for variables whose lifetime the compiler can verify automatically at compile time (mainly for local scopes).
- The identity of data types includes not only reference types, but also the methods of inter-thread access synchronization.
- Since interaction with C++ code is required, it is impossible to completely abandon raw pointers to data, but strict restrictions are introduced for them at the level of the compiler (static analyzer) in order to limit errors when working with memory.
- Working with memory must also include protection of the stack from overflow.
The current memory management model is at the testing stage and will be documented in version 0.7.0. These and other project concepts can be discussed on Reddit https://www.reddit.com/r/trust_lang/