Java style field initializers - please drop the C++ initialization vector (or at least don't require it)

[DartBot]

This issue was originally filed by maraist...@gmail.com

---

I was very confused to see a hybrid of java, C++ and javascript in the constructors of Dart.. I'm not understanding the particular reasoning.

In C++ we initialize all class-fields in the constructor initialization-vector (illegal to initialize fields directly). Anything not explicitly listed has an implicit ordered item. While this allows static functions to be called that leverage field-order + constructor-parameters as it's only state, this is cludgely and a half. For non-final fields, you can perform the initialization in the constructor-body, BUT, we tend to prefer to use the initialization-vector to avoid the innefficient copy-constructor followed by operator=

class Foo {
  Bar bar;
  Foo(const Bar& _bar) : bar(_bar) {} // efficient copy-constructor
  Foo(bool useBar, const Bar& _bar) { if (useBar) bar = _bar; } // innefficient, default-cons, then operator= called
};

If it wasn't for the possibility to avoid this duplicate initialization, I doubt the constructor-vector would have even been invented in C++.

Java fixes this in 3 ways.

1. It allows multiple [anonymous] pre-constructors
2. It allows fields to directly initialize their values (by essentially treating each field with an assignment as a separate anonymous pre-constructor)
3. It allows final/const fields to be structurally analyzed to verify that all defined constructor paths will result in either an exception or the assignment of all final/const fields. This allows constructor-initialized programaticly computed final values.

class Foo {
  int x = 5; // implicit anonymous pre-constructor
  Map items = new HashMap(); // implicit anonymous constructor
  // explicit anonymous constructor
  {
    items.put("one",2);
    items.put("two",3);
  }

  static int y;
  // anonymous static constructor (no corresponding named static-constructor)
  static {
     y = Factorial.compute(System.getProperty("fact"));
  }

  final int z,w;
  {
     z = 8;
  }
  Foo(bool useBool) {
     if (!useBool) throw new RuntimeException("");
     w = 9; // initializes final field w
  }
}

Arguably 3 is really hard to accomplish for a new compiler writer, and requires that ALL code paths be in the same compilation-unit (so it can be responded to with compilation errors).

But honestly, Darts field initialization makes for nasty code and high degree of surprise for both Java and C++ people.. Namely: You CAN inline initialize numbers (like in java). You CAN'T initialize objects (which you can do in Java, and you CAN do in C++ through the use of default constructors). You can't use code-analysis to initialize final fields inside the constructor body (e.g. it's more like C++). You HAVE C++ vector initialization (which freaks out Java people who hate that Stroustrup was even born), but this means you have cludgey syntax when you need non-trivial initialization of final fields. You MUST have a long and complex initialization vector full of 'new's

// Dart
class Foo {
  final List list; // can't inline initialize like Java OR C++

  // can get akward that MOST initialization code must appear
  // in initialization vector. How to validate prior to assignment?
  Foo(x,yz,) : list = const[x,y,z] {}
}

I'm not sure if there is some latent intent to make a C / C++ version of the back-end of Dart, and thus C++ is part of the least-command-denom.. If not, this this is just madness. As a VM can trivially handled constants at runtime. Namely leverage anonymous pre and post constructors. And for all final fields, apply a post-constructor which asserts that all final fields have been assigned. In the javascript side, who cares if it was really initialized or not because javascript doesn't even have final fields.

And here's the worst part..
Let's say you have 30 fields that are complex objects (lets just assume they're all lists that need "new List()" calls).

In Java, EACH incrementally newly added field can just be

List myNewField = new List();

And then some method somewhere uses that list.

In C++ it's even easier:

std::vector myNewField; // non-heap default-constructor

But in dart, we have

  List myNewField; // invalid null

  Foo(): list1 = new List()
     , list2 = const[1,2,3]
     , myNewField = new List() // ok, I remembered to add it here
  { }

  // OPS, forgot to initialize it here.. F* me.
  Foo.newfactory(): list = new List(), list2 = const[1,2,3] {}

Further, as you can see, the number of fields times the number of named constructors is the number of annoyance. Yes you can create _init(); that does all this, but I tend to only look at those as a configuration-of-last-resort.. Remember, this was an incremental change/addition.. Perhaps we didn't have an _init() method already.

[DartBot]

This comment was originally written by marai...@gmail.com

---

So just to recap.

Make it legal to perform:

class Foo {
 var x = [1,2,3];
 List y;
 Foo(a,b,c) : y = const[a,b,c] { }
}

It's win-win. The javascript for this is trivial. The VM for this just needs the notion of anonymous pre-constructors.

[DartBot]

This comment was originally written by drfibonacci@google.com

---

Removed Type-Defect label.
Added Type-Enhancement, Area-Language labels.

[DartBot]

This comment was originally written by drfibonacci@google.com

---

Added Triaged label.

[gbracha]

I think you are missing the point here. Unlike Java, we can guarantee, for all fields you initialize via the initializer list, that they will never be seen in uninitialized state. You can redirect constructors easily so you really need not duplicate field initialization.

Anyway, we're gathering feedback, so we'll take it under review.

---

Set owner to @gbracha.
Added Accepted label.

[DartBot]

This comment was originally written by marais...@gmail.com

---

I understand what you're trying at accomplish, but I viewed Java as an evolution over C++'s initialization process, and my initial impression was that dart was regressing to C++-isms, which are frustrating, error-prone, ugly, and not necessary.. I hear what you're saying that there might be something I'm missing with respect to redirection.

I'll review the spec more closely with respect to constructor redirection, but my first impression was 'how is redirection different than "Foo(x) {this(x,1);} " or "Foo(x) {super(x);}"'.

To re-iterate
C++ initialization can surprise developers:
class Foo {
  const int id, y;
  // legal in C++, id is initialized before y, so y can refer to id
  Foo(): id(computeId()), y(id+1) { }
  // not legal, but MIGHT compile with garbage for 'id'
  Foo() : y(0), id(y+1) { }
}

Further, C++ allows stack-like initialization for zero-arg constructors, which I often see leading to 'forgotten' initialization fields:

class Foo {
  const std::vector<int> x, y /* y added later */;
  Foo(int size) : x(size) { } // ops, forgot y
}

In Java, we'd have one of two basic models
class Foo {
  final List x = new List();
  final List y = new List(); // added later, BUT better guarded against copy-paste errors
  Foo() { .. } // doesn't care about initialization
}

or
class Foo {
  final List x;
  final List y; // added later
  Foo(int size) {
     x = new List(size);
     y = new List(size); // Is a compiler error to omit
  }
}

While, as I said, I need to read more into what you're attempting with const's and redirects, I'm not currently seeing why this java-style compile-time static-code-analysis can't produce the same outcome as a const C++ structure but with fewer syntactic danger-zones.

[gbracha]

Well, the first example cannot happen, because the initializers cannot be dependent on each other. They cannot see "this".

The second concern has more validity to it. If you add a field, you need to update the constructor that does the initialization. If it is a final field, the compiler will force you to do so (and I'd make fields final wherever possible - most fields don't change after initialization). But a non-final one could be overlooked I suppose. I'd assume you add its initialization when you add the field. I'd also try and stick to one generative constructor and have other redirect, but that may not work for everyone all the time.

We're reluctant to add all the Javanese baggage of definite assignment and unassignment, but we'll see.

[DartBot]

This comment was originally written by ma...@gmail.com

---

One last thing use-case I forget to mention (if you'll indulge me):

// C++
class Foo {
  const int size;
  const int mask;
  const int maskM2;
  Foo(int _size) : size(_size), mask(computeMask(_size)), maskM1(computeMask(_size) - 1) { .. }
}

Here, in order to have the benefit of a const I have to perform all my computations in a static context that does not have access to temporaries. I believe C++ allows me to make maskM1(mask - 1) (as I listed above), but then you have the fear that somebody re-arranges the variable order one day. It's hard to read, and leads to duplicate computation and bloated syntax. The above with static syntax checking in java is:

// Java
class Foo {
  final int size;
  final int mask;
  final int maskM1;
  Foo(int size) {
    this.size = size;

    // compute mask inline
    this.mask = // computed value

    this.maskM1 = mask - 1;

    // ...
}

[DartBot]

This comment was originally written by asgerkl...@gmail.com

---

I think one can reap the benefits of Java's field initializers and also avoid its problems using two restrictions:

1. the initializer for a non-static field may not refer to "this", but may otherwise be an arbitrary expression
2. the initializer for a static field must be a constant expression (the current restriction)

The first rule prevents "this" from escaping, and therefore the initialization of the first field cannot accidentally look at the (uninitialized) second field. This is essentially the rule from C++ mentioned in comment #­6.

The second rule is to avoid Java's static class initialization, in which the order of initialization can be rather unpredictable.

This should not add significant complexity to the analysis of final fields.

I am not arguing against the initialization vector. I just wish Dart was more liberal with field initializers, as they are a lot more convenient than manual initialization in a constructor.

[anders-sandholm]

Added apr30-triage label.

[anders-sandholm]

Removed apr30-triage label.

[anders-sandholm]

Added triage1 label.

[anders-sandholm]

Removed triage1 label.
Added WontFix label.

[DartBot]

This comment was originally written by @tomyeh

---

Too bad to know it was marked as WontFix. Dart is a great language and combine a dynamical language and strong typing nicely. However, the initialization (final filed or static files) is really restricted. In some degree, it forces developers not to use final since it is too inconvenient.

[gbracha]

You will note that for static variables, the rules have been changed in a very significant way (lazy initialization). The remaining issue is instance variables, and we have considered a number of options, none of which seems attractive at the moment.