Chapel: Should "new initializers" support field initialization prior to super.init()?

[bradcray]

In issue #8283, the assumption is that in the new init() definition, a class's fields
can't be initialized prior to the call to super.init() (the initialization of the ancestor
class fields). This issue asks the question "Should we permit fields to be initialized
prior to the super.init() call?" as an extension to the core proposal. It is designed to
collect thoughts, feedback, advantages, and disadvantages.

To seed the discussion some of the tradeoffs mentioned in a meeting today were:

Advantages:

• enables more flexibility / less strictness in terms of how an initializer is written
• may permit more existing initializer code to persist without being rewritten

Disadvantages:

• may add more complexity to the compiler implementation

[bradcray]

Here's another disadvantage that was mentioned which seemed lengthy enough to warrant its own comment:

Enabling fields to be initialized early could result in user confusion when things go wrong. E.g., in cases where it would cause a compiler-generated initialization to occur too early, as in the following example:

class A {
  var n = 10;
  var D = {1..n};
}

class B : A {
  var x = 10;
  var y: [D] real;
  var z: real;

  proc init(x) {
    this.x = x;
    // compiler would insert default initialization of this.y here
    // causing a use-before-def error for `D`.  What error message
    // should be generated to clearly help the user understand and
    // fix the issue?
    this.z = 3.1415;
    super.init();
  }

[bradcray]

Speaking for myself, and not the impartial capturer of discussion that I tried to be above, I
think that we should start with the stricter definition (require a call to super.init() prior to
initializing any child class fields) and see how onerous it is as a starting point. This seems
similar to our current approach that fields must be initialized in order even though there may
be cases where the compiler could tolerate different orderings without getting confused. It
seems clearer, easier for users and the compiler to ensure is correct, and more likely to
support clear error messages. If, with experience, we find the current approach too
burdensome or inflexible, and can convince ourselves that we can generate good error
messages after relaxing it, we should consider it then.

[lydia-duncan]

I would like to see this supported eventually for the sake of friendliness, but agree that we should start with the stricter definition and ensure we have a helpful error message for the cases that would be confusing (and think it is unlikely we will encounter a case that needs to allow this to happen)