Assignments are statements that set the value of a field to the result of the evaluation of an expression.
In Fuzion, static code analysis ensures that no fields are called before an initial value has been assigned to the field.
A program that may access uninitialized fields does not compile:
Fields may be reassigned.
The following example updates field
a, first by a direct
assignment, and then by a call to a routine
addToA that adds a
A routine may update its own fields and fields of outer features. But it is not permitted for a routine to update fields of other instances.
It is not even possible to update a field in a different instance of the current feature:
A field that has no assignments except the initial assignment is called an immutable field. For most situations, it is fully sufficient to work with immutable fields. E.g., variables that are declared and assigned in a loops for-clause are immutable since every loop iteration creates a new instance of such a variable.
In Fuzion, the developer is encouraged to avoid mutable fields. The following sections of this tutorial will present techniques to avoid field updates. Using these techniques will enable compiler optimizations that are not possible with mutable fields. Immutable fields will also be a basic prerequisite for Fuzions safe concurrency model.
However, if desired for performance reason or out of convenience, it is possible to mutate fields. The Fuzion compiler will then analyse the uses of such a field and detect potential errors such as race conditions and flag an error in this case. It will not be possible to access mutable variables from different threads or to export a feature that depends on a mutable field from a library.