Initializers¶

Phase 1¶

The code residing in Phase 1 must follow a set of strong requirements.

Other methods on the this instance cannot be called. The this instance may not be passed to another function.

Fields must be initialized in declaration order; however, fields can be omitted. Omitted fields are given the declared initial value if present, or the default of its declared type. Fields with neither a declared initial value nor a declared type cannot be omitted.

class Foo {
  var bar = 10;
  var baz = false;
  var dip: real;

  proc init(barVal, dipVal) {
    bar = barVal;
    // omitted initialization: baz = false;
    dip = dipVal;
    super.init();
  }
}

var foo = new Foo(11, 2.0);

Both explicit and implicit initialization of a field can depend on the values of prior fields. However, later fields may not be referenced.

class Foo2 {
  var bar = 10;
  var baz = 5;
  var dip = baz * 3;

  proc init(barVal) {
    bar = barVal;
    baz = divceil(bar, 2);
    // omitted initialization: dip = baz * 3;
    super.init();
  }
}

var foo2 = new Foo2(11);

Parent fields may not be accessed or initialized during Phase 1.

const fields may be initialized during Phase 1. Local variables may be created and used. Functions that are not methods on the this instance may be called, so long as this is not provided as an argument.

Loops and parallel statements are allowed during Phase 1, but field initialization within them is forbidden. on statements whose bodies extend into Phase 2 are not allowed, but more limited on statements are acceptable.

When Phase 1 of the initializer body has completed and the phase division indicator has been processed, it can safely be assumed that all fields are in a usable state.

Phase Division Indicator¶

An explicit call to another initializer ends Phase 1 and begins Phase 2. This call takes one of two forms:

Form 1: call to an initializer defined on the parent type

super.init();

Form 2: call to another initializer defined on the same type

this.init();

If the type has no parent, an argument-less call of the first form will still be valid, but otherwise treated as a no-op.

Example of initializers using the first form:

class Foo { // no parent type
  var x: int;

  proc init(xVal: int) {
    x = xVal;
    super.init(); // argument-less call ends Phase 1
  }
}

class Bar: Foo { // inherits from Foo
  var y: bool;

  proc init(yVal: bool) {
    y = yVal;
    super.init(10); // Calls the parent initializer
  }
}

var bar = new Bar(true);

When using the second form, field initialization statements are not permitted in Phase 1, though other statements are allowed. Omitted field initialization will not be inserted prior to calls of the second form.

Example of an initializer using the second form:

class Rectangle {
  var len, width: int;

  proc init(val: int) {
    this.init(val, val); // calls the other initializer
    writeln("Making a square");
  }

  proc init(lenVal: int, widthVal: int) {
    len = lenVal;
    width = widthVal;
    super.init();
  }
}

var square = new Rectangle(4);

For a single control flow path through the body, only one phase division indicator is allowed. It is forbidden to have both calls, or multiple of either, in a single control flow path. It is forbidden to enclose the phase division indicator in a parallel statement, on statement, or a loop statement. If the phase division indicator is enclosed by a conditional, it must be a param conditional.

If no phase division indicator is provided, an argument-less first form call will be inserted at the beginning of the body. The Compiler Generated Initializers will also include an argument-less first form call after completing the initialization of its fields. If the parent type has defined an initializer that this call cannot resolve to, attempts to initialize the child with the compiler generated initializer will result in an error.

Phase 2¶

Code in Phase 2 is functionally similar to other methods on the type, and less restrictive than code in Phase 1. Modifications to the fields are considered assignment rather than initialization. Other methods may be called on the this instance, and the this instance may be passed as an argument to another function. Parent fields may be accessed.

As in other methods, code in Phase 2 may not redefine const, param, and type fields.

Compiler Generated Initializers¶

Prototypical support of compiler generated initializers has been added. With the 1.16.0 release and the developer-oriented flag --force-initializers, user-defined classes will attempt to generate default initializers instead of default constructors. User-defined records, and records and classes defined in the internal, standard, or package modules will not yet generate default initializers with this flag. However, there are still failures with even that limited application.

It is anticipated that compiler generated initializers will be fully supported in the next release.

Interaction With Error Handling¶

Due to time constraints, the 1.16.0 release went out with very limited support for error handling constructs: an initializer cannot be declared as throws, and only try! statements without catch blocks are allowed in the body.

In later releases, we hope to support throw, and try and try! statements with catch blocks during Phase 2, allowing initializers to be declared as throws. It may be possible to allow these constructs in Phase 1, though for simplicity's sake they will likely still be banned around field initialization statements and forbidden from crossing the Phase 1/Phase 2 divide.

In the world where initializers can throw, we will only allow child classes to throw if the parent initializer throws (though there may be complications with chains of initializers, such as an initializer that calls another initializer on the type, which calls a parent initializer that throws, etc.).

Noinit¶

Variable initialization when provided the noinit keyword in place of an initial value for a class or record should generate a call to an initializer that has defined what noinit means for that type. More details on the direction for this support can be found in the noinit section of CHIP 10.

Bugs¶

• secondary initializers in outside modules when the type doesn't define an initializer in its original module
• nested types when the outer type and/or the inner type defines an initializer and the outer type and/or the inner type is generic.
• others

Other TODOs¶

• Convert library types to utilize initializers instead of constructors
• Improve some slightly cryptic error messages
• Ensure we always error when a method is called in Phase 1 (we only sometimes do today)
• Extend on statement support to allow field initialization within its bounds after getting larger team buy in.