New Issue: initializers and typeless fields

Notifications Issues
1

16508, “mppf”, “initializers and typeless fields”, “2020-09-29T18:20:54Z”

Follow-on to #12318

Issue #12318 discusses a language design direction that can handle typeless fields better.

We still have problems with the language design in this area. The main problems are around type aliases (and/or partial instantiations) and typeless fields.

For example:

record GenericTypedFieldWithInit {
  var f:numeric = 1;
  proc init() {
    this.f = 1.0;
  }
}
var x = new GenericTypedFieldWithInit(); // runs init()
var y: GenericTypedFieldWithInit; // should run init() but doesn't work yet on master
var z: GenericTypedFieldWithInit(int); // how can the `init` called respond to the fact that `f.type` is already `int` ?

According to #12318, initializer authors will use two features to be able to write an init that responds to the various possibilities:

  1. Using this.type to query elements of the type. This is already possible in init= functions but not yet in init
  2. A way to get the default value for a particular type. This is important for typeless fields cases.

However we currently have implemented a pass-type-alias-arguments-as-named-arguments-to-initializers strategy (TODO: link to wherever this is documented). Does a user trying to write a proc init for GenericTypedFieldWithInit above need to create one with signature proc init(type f) for the compiler to pass the type of f into? That seems strange since the field f is not a type but rather a value. Should this information be passed exclusively through this.type - and in that event do we need to change something about the pass-type-alias-arguments-as-named-arguments-to-initializers strategy? Or, should the compiler try to call proc init(type fType) or something along those lines?