What are the approaches of protecting against partially initialized objects?

Question

An object is partially initialized if the program execution didn't exit their constructor yet. Usually the programmer is responsible for not leaving partially initialized objects in unwanted places and calling them in unwanted ways. But like Rust has "ownership" and "lifetime" to protect against invalid pointer accesses, are there ways to protect against misusing partially initialized objects, while still allowing every operation that does useful work in the constructor?

My knowledge about Rust is limited, but if there aren't some edge cases that I don't know, it doesn't seem to have accessible partially initialized objects at all. But I'm thinking about languages with more traditional constructors like in C++.

The background of this question is, I'm thinking about how much damage could be done, if there could be async constructors, and objects are allocated in-place instead of referenced from elsewhere, which could leave a lot of partially initialized variables in random places.

Example C++ code that referred to an uninitialized object in this way:

#include<iostream>

struct D {
    int x;
    D(){x=12345;}
};

struct A {
    int y;
    A();
};

struct B:A {
    D d;
    int dx(){return d.x;}
};

B b;

A::A(){std::cout<<b.dx()<<std::endl;}

int main(){}

Answer 1

There are two related issues here: one is memory safety, and the other is domain invariants. We want to guarantee fields are initialised, because an uninitialised field with whatever bit pattern was previously left in that field's location might not be valid for the field's type (e.g. it may be a number out of range, a pointer to an object of the wrong type, or a stale pointer to an object which no longer exists). Additionally, we may also want programmers to be able to ensure their own invariants (e.g. for a Range type, that this.start <= this.end).

Definite assignment

By static analysis, a compiler can determine that a field is or isn't "definitely assigned" at each point in the constructor. The goal is to check that all fields are definitely assigned before a reference to the object can escape (by any means).

This may be done via syntax-directed rules, as Java does (albeit not for fields): for example, a field x is definitely assigned after a statement this.x = ...;, a field is definitely assigned after if(...) A else B if it is definitely assigned after A and definitely assigned after B, and so on. Alternatively, a control-flow graph can be derived, then a variable is "definitely assigned" if every exit node is dominated by an assignment to that variable.

Such rules are conservative, so it is possible to write programs which in reality always assign to a variable, but which nonetheless don't satisfy the rules. The compiler will reject such programs; this could upset programmers who "know better than the compiler". Typescript offers an escape-hatch via definite assignment assertions, allowing the programmer to override the compiler's judgement, although (like other escape hatches) this means opting out of having the compiler check the correctness of your code.

Definite assignment checks are based on the principle of proving that the fields will be assigned after some statement or set of statements complete normally. This means that separate guarantees need to be made for when the constructor does not complete normally (e.g. if it throws an exception, yields, or falls into an infinite loop). In those cases we want to ensure that a reference to the uninitialised object cannot be acquired. The rules to ensure this can often be more onerous than the more straightforward rules requiring definite assignment before the constructor terminates.

Normally, a reference to a partially initialised object can't escape from the code which invokes the constructor, since it receives no such reference in case the constructor fails (or, if the constructor is merely paused, the invoking code doesn't receive a reference to the new object until the constructor resumes and completes). However, the constructor itself must also not provide other code with a reference to this before all fields are initialised; in particular, instance methods should not be called, nor should a superclass constructor. (Alternatively, if a superclass constructor may be called earlier, then instance methods must not be called from anywhere in the superclass constructor, even after all superclass fields are definitely assigned.) If you allow constructors to yield, then likewise a constructor must not yield this (or similar) before all fields are initialised.

Default field values

In Java, fields have default initial values based on their types, such that a field has a well-defined value even if is not assigned in the constructor (or an initialiser). This is a semantic guarantee rather than a runtime requirement, so a compiler is permitted to optimise away the assignment of the default value if it is a dead store.

This means that objects in Java always have their fields initialised, guaranteeing memory safety and preventing implementation-specific behaviour, though it is not guaranteed that a default initial value for a field will satisfy any invariant intended by the programmer.

Note that this is only possible in Java because null is a valid value for all reference types. In general, non-nullable reference types do not have sensible default values, nor do function types, file handles, or so on.

Allow fallible constructors

In languages with exceptions, constructors can be permitted to throw them. This allows programmers to throw exceptions rather than allow objects to be created which violate their invariants. However, it doesn't help with memory safety since it depends on the programmer writing code to verify the object's state themselves.

Ban fallible constructors

A different approach is taken by languages like Rust, in which there are no non-trivial constructors or initialisers at all. Objects (really, structs and tuples) are created by directly providing values for all of their fields, and so it is trivially not possible to "see" an object before those values are assigned.

This guarantees memory safety, but means invariants (and other considerations such as encapsulation) must be addressed in a different way. Rather than writing a constructor which checks whether the object is being constructed correctly and throws an exception otherwise, programmers are expected to write factory functions which perform those checks before creating the object.

Answer 2

The general problem you describe is to allow computations on constructors, and at the same time to avoid partially constructed objects that do "escape" into other contexts. This is something that linear type theory may help.

Two stage construction constructor

Inside the constructor, the object has a special type that cannot be expressed in code. And a syntax to mark the completion of the constructor, to allow a normal object to interact with the system, even inside the constructor.

class C {
    def constructor( self, args... )
    {
        // self starts as an "unborn" object.
        // It's already allocated, but no invariants hold.

        // Also, self.c cannot be null and also cannot
        // mutate after construction (init only).

        self.a = ...;
        self.b = ...;

        MyCache.Add(self); // Compiler error: Unborn object cannot escape.
        self = new;        // Compiler error: Unassigned property.

        self.c = ...;

        // This completes the constructor, and guarantees all invariants
        self = new;

        MyCache.Add(self); // This is ok.
        self.c = ...;      // Compiler error, immutable read only property.
    }
}

var c = new C( args ... );
MyCache.Add(c);            // This is ok.
c.c = ...;                 // Compiler error, immutable read only property.

Do not store references of partially constructed objects

This may sound silly, but is a long standing gotcha in Java and also in other languages, more close to metal. See the size of code for double-checked locking examples in Wikipedia!

The misconception is that:

singletons[i].reference = new Singleton();

means:

1. Allocate instance
2. Run constructor
3. Store object reference

But in multi-threaded C/C++/Java this also means:

1. Allocate instance
2. Store object reference
3. Run constructor

So an another thread can access singletons[i].reference and get a reference to a non constructed object. This invalidates all invariants!

For example, any non-null object property can now return null values. How bad is that?

Allow constructors to fail graciously

Running computations on a constructor means that these computations can fail. But if the only way to communicate these failures is to throw exceptions, the code may end up cluttered with exception handling code, even these failures are expected.

A gentle way is to allow constructors to fail more graciously

def constructor ( self? , args... )
{
    // Note the ? on self parameter.
    // This means that this constructor may not create an object.

    var memory = malloc( 1000 );
    if ( memory == null )
        return null;
}

And by so, code now can be more simple:

var fileinfo = new FileInfo(path) ?? FileInfo.Empty;

// or

var fileinfo = new FileInfo(path); // fileinfo is FileInfo?
if ( fileInfo ) { ... }            // fileinfo is FileInfo inside if
else { ... }                       // Failed to obtain file fin

Allow constructors to return errors

Same as above, buy we are interested on why FileInfo constructor failed.

def constructor ( args... ) self , error
{
    // Multiple returns on constructors are always disjoint unions
    // Alternative, explicit syntax:
    //
    //     def constructor () self |,| error

    if ( ... )
        return self;
    return (error) err;
}

var info, err = new FileInfo(path);

Console.Log( info.FileSize ); // Compiler error, disjoint type direct access.
throw err;                    // Compiler error, disjoint type direct access.

if ( info ) { ... } // Ok
else throw err;     // Ok
```

Answer 3

The simplest method is to by default initialize to something as soon as the lifetime of an object begins.

In D this is the Foo.init value which every type has which gets memcopyd onto the variable when the lifetime begins. It can be customized in the definition of the struct. You can also just pick zero as initial value for everything.

Then you can opt-out by declaring the initial value of your variable as void: Foo f = void;

Straight forward compiler optimizations will let dead stores (where a field gets written twice without being read inbetween) get optimized out in the common case.

Using this scheme means that the programmer will need to opt-into uninitialized values.

Designing a constructor around making an object immutable after construction can be done by making the constructor the exception to not being able to write to the non-mutable fields (the others are still default init where it matters). Or by delaying actually writing the fields until a designated point in the constructor. Then you have a preamble that computes the actual fields after which the fields get written and the lifetime officially begins, and a epilogue where it might fit itself into a datastructure as it might need.

Answer 4

I'd like to add an interesting solution Bob Nystrom used in one of his languages, Magpie (explained in this article):

Basically, every class has a factory method, new, which by default simply creates an object using the given parameters and can be overridden to supply some more complex initialization logic. The trick is that within these methods, there's no way to actually access any instance variables of the new object, since it hasn't actually been created yet!

Instead, at the end of that method you call another, built-in method called construct, which takes in a record (basically a map) containing a key and value for every instance variable, and returns a new instance of the specific class initialized accordingly. That way, instance creation is atomic, meaning it is completely prohibited by design to perform operations on a partially initialized object.