Mentioning it now, but may want to come back later when need to know.
On functions and blocks
Pure for initialization, covered later
Trust blocks: Relaxing Safety Checks
The compiler comes with built-in guard rails to help protect your code against a number of safety hazards, which is a good thing. However, these safety guards are extremely cautious and not always very clever. They stop your code from doing things that, under the worst of all possible conditions, could cause memory or race conditions. Sometimes this means they stop your code from doing things that you want to do, and which you can ensure by other means is perfectly safe, but the compiler just does not know how to verify. The compiler is trying to be helpful, but is just getting in the way.
In such situations, Cone provides a built-in escape hatch from the guard rails, in the form of an annotation. By preceding any block with trust (as in: "trust me on this"), several safety checks are turned off, thereby allowing:
- Raw pointer dereferences, arithmetic, and re-casts. This provides a way to get around the many constraints imposed on references by permissions, lifetimes, allocators and bounds-checks.
- Use of functions written in and imported from other languages. This is normally disallowed since most other languages are not as rigorous in verifying the safety of the code.
- Static mutable variable access and mutation. This guard exists to protect against race conditions in multi-threaded code.
Safety is enriched when the programmer and the compiler work together towards that end, each bringing different gifts to bear on the problem. It would not be fair to imply that the compiler's inability to verify safety means that the code is inherently unsafe. By using this "trust" mechanism, compiler-unverifiable code can be isolated and highlighted as such, while still acknowledging that the programmer, who has the ultimate responsibility for safety, may very clearly see what the compiler cannot.