Const¶

Const Values¶

const prevents modifications of values. For example, the following code is invalid:

void function() {
        const int i = 0;
        i = 1;
}

In this case the compiler will complain that the underlying lvalue has a require predicate for its assign method that specifies the const int type must be movable; const types are not movable and therefore the assignment cannot occur.

Const Pointers¶

Here’s another example of invalid code:

void function() {
        int i = 0;
        const int* p = &i;
        *p = 1;
}

While i can be modified directly, p refers to const int and therefore assignment is again not possible.

Const Predicates¶

It’s possible to specify that a value is const based on the result of a predicate:

template <bool IsConst>
const<IsConst>(int)& function(const<IsConst>(int)* ptr) {
        return *ptr;
}

This function will work with both const and non-const values while remaining type safe. This is not possible in C and can only be achieved in C++ via function overloading.

Methods¶

Methods can be marked as const to indicate they do not modify their owning object.

class ClassObject {
        void normalMethod();
        void constMethod() const;
}

void f(const ClassObject& object){
        // Invalid - non-const method cannot
        // be called on const object.
        object.normalMethod();

        // Valid.
        object.constMethod();
}

It’s possible to specify a predicate within the const declaration. For example:

interface RunnableType {
        void run();
}

interface ConstRunnableType {
        void run() const;
}

template <typename T>
class RunWrapper {
        void run() require(T : RunnableType) const(T : ConstRunnableType);
}

The run() method of RunWrapper requires that T has a run() method, using a require() predicate. Furthermore, if the run() method of T is const then the run() method of RunWrapper will also be const.

selfconst¶

selfconst is a convenient mechanism to indicate that a method signature (typically the return type) depends on whether self is const:

class Array {
        selfconst(int)& index(size_t size) const noexcept;
}

This tells the compiler that the index() method won’t modify the Array object, however it can return a non-const reference if self is non-const.

selfconst can also be used as a predicate value; selfconst(Type) is equivalent to const<selfconst>(Type).

Cumulative¶

const is cumulative, meaning that an application of const() to a type cannot reverse the effects of any previous application of const() to the type.

Each application of const() is a logical OR with the type’s existing const predicate. So const<A>(const<B>(Type)) is equivalent to const<A or B>(Type).

This property of const is particularly relevant to templates:

template <typename T, bool Predicate>
const<Predicate> T& f(T& value) {
        return value;
}

void g() {
        const int i = 10;
        int& r = f<const int, false>(i);
        // Did we get a non-const reference to a const object?
}

For the templated function f(), T may or may not ultimately be const. If const was not cumulative then the cast from T& to const<Predicate> T& in f() would actually be invalid for the invocation f<const int, false>, because it would be performing a cast from const int& to int&.

However const is cumulative so f() is actually performing a cast from const int& to const int&, which is valid. The error is therefore in g(), which is attempting to cast the const int& returned by f() to int&.

Relative¶

const is relative, since templated code may interact with a const object as if it were non-const.

interface CalculatorAPI {
        int calculate();
}

template <typename T: CalculatorAPI>
int f(T& value) {
        value.calculate();
}

class Calculator {
        int calculate() const;
}

int g(const Calculator& calculator) {
        return f<const Calculator>(calculator);
}

In this code f() sees T as a non-const variable and calls a non-const method on T. However g() sees const Calculator with a const method. Despite this apparent contradiction, the code is valid.

This works because f() knows that T must satisfy CalculatorAPI otherwise the instantiation would fail. The calculate() method of CalculatorAPI is not marked const, but this doesn’t mean the real method being called can’t be const (the opposite way around would be an error).

Transitive¶

const is transitive due to restrictions specified by the language’s primitive types (e.g. ptr_t, which is the underlying type of a pointer). These restrictions necessarily mean that const is also transitive for custom types built on these primitives.

As a result of this, syntax such as int* const is replaced by const(int*), to be clearer that both the pointer and the int to which it refers cannot be modified via this reference:

void function() {
        int i = 0;
        const(int*) p = &i;
        *p = 1; // ERROR!
}

This is unlike C and C++, for which const is not transitive for pointer types:

void function() {
        int i = 0;
        int* const p = &i;
        *p = 1; // This is valid.
}

Not only is the syntax much simpler here but the semantics of transitive const are much more obvious. For example, consider:

struct Example {
        int* value;
};

void function(const Example exampleInstance) {
        *(exampleInstance.value) = 42;
}

This code would be valid in C++ but is invalid in Loci. The intention behind this approach is to provide behaviour that is clearer and more closely matches the intuition of developers.

Overriding Const¶

As part of logical const, Loci provides the ‘__override_const’ keyword (similar to mutable in C++), which allows const methods to modify a member variable marked __override_const.

class ComplexResultCalculator(__override_const int result) {
        static create() {
                // Assume that the result can never be zero.
                return @(0);
        }

        int calculateResult() const {
                if (@result == 0) {
                        @result = performSlowCalculation();
                }
                return @result;
        }
}

ComplexResultCalculator uses __override_const to provide caching behaviour in a const method, which is a valid use case. This relies on ComplexResultCalculator correctly invalidating its cache when necessary (e.g. if a non-const method could affect the calculation result).

Other suitable use cases for __override_const:

• Reference counting (e.g. shared_ptr) - Changes to the count don’t affect the current reference, hence the reference count is not observable.
• Locking - Some classes may wish to lock a mutex to be thread-safe in const methods; the locking/unlocking is not observable.