I was trying to start doing a record for a composite type (vector of ints) but keep getting hung up back on something that must be basic that I'm missing. I've boiled it down to the following which seems like it should be valid.
Thinking like C++ programmer I'm not sure I appreciate the significance of "init"s vs. constructors and assignments. If I do chapel with those, it eventually complains about missing "init=" which takes me down the whole "init" path.
[u2:Chapel] chpl --version
warning: The prototype GPU support implies --no-checks. This may impact debuggability. To suppress this warning, compile with --no-checks explicitly
chpl version 2.3.0
built with LLVM version 19.1.3
available LLVM targets: x86-64, x86, nvptx64, nvptx
Copyright 2020-2024 Hewlett Packard Enterprise Development LP
Copyright 2004-2019 Cray Inc.
(See LICENSE file for more details)
[ugpu2:Chapel] cat bug.init.chpl
config const N : int = 4;
type T = uint(32);
record MP {
var val : [0..#N] T;
proc init() {
for i in 0..#N do this.val[i] = 0;
//this.val = 0; // does work instead
}
};
var A : MP;
[u2:Chapel] chpl bug.init.chpl
warning: The prototype GPU support implies --no-checks. This may impact debuggability. To suppress this warning, compile with --no-checks explicitly
bug.init.chpl:9: In initializer:
bug.init.chpl:10: error: field "val" used before it is initialized
@justapony: Chapel's initializers are somewhat akin to C++'s constructors, but because Chapel is designed to promote type safety, its rules are defined to ensure that all fields of a class or record are initialized prior to that field, or the object as a whole, being used. This results in it being somewhat more particular about what appears in the initializer and where. Where C++ uses parenthesized expressions in the lead-in to the constructor's body to initialize fields, Chapel uses the initial statements within the initializer's body to serve this purpose.
Specifically, Chapel currently requires that the object's fields must be initialized in their declared order using an initialization of the form [this.]field = initExpr;, which is why this.val = 0; (or simply val = 0; or even this.val = for i in 0..#N do 0;) works, yet for i in 0..#N do this.val = 0; doesn't. Effectively, in that loop, the compiler sees a reference to the val field before an (obvious) initialization of it via a [this].val = …; initializing assignment.
With more work, you could imagine the compiler being taught to understand that your loop is guaranteed to initialize all elements of val, and that a loop like for i in 0..#(N/2) do this.val = 0; would not, but to date, the language has opted for only supporting the simpler model of just looking for whole-field initializations and balking if it sees uses of the field before that.
Here's an explanation of the difference between initializers (init() procedures), copy initializers (init=() procedures), and assignments (operator =):
init(...) routines can be thought of as being like C++ constructors and are invoked in the following cases:
calls to new myType(...) for records or classes
declarations of the form var r: myRecordType; or var r: myGenericRecordType(…); for records, modulo split initialization (see next section)
In contrast, the init=() routine can be thought of as being like a copy constructor in C++, and will be invoked in cases like:
var a: someType = someExpr; (for an expression other than new …) will initialize a via a call to someType.init=(someExpr)
var a: someType; … a = someExpr, where the code between the declaration and that first assignment is sufficiently trivial, treats the assignment as an initialization of a. This is referred to as split initialization and is a pattern that's can be useful when a variable can't be initialized at its declaration point. See this section of the spec for details.
The first [this.]field = someExpr; assignment in an initializer or copy initializer, which is considered to be an initialization (and can also be viewed as a form of split initialization).
Meanwhile, any = after the initialization of a variable or field is treated as an assignment, and the assignment operator will be used. The reason that it's important to distinguish assignment from initialization, is that in an assignment, the target of the assignment will already store a value that may require cleaning up, whereas in an initialization, it's known that the variable isn't storing anything yet.
Part of the obvious source for confusion here is that the = symbol can mean assignment or initialization depending on context, so it's not always visually obvious which it is. At times, we've considered adding an explicit init= operator so that a user could write this.val init= initExpr; (say) to be very explicit in their code. But even if we did that, I wouldn't expect Chapel to require it to be used in all initializing contexts since things like var x init= 42; reads so much more cleanly as var x = 42;.
Hopefully the above answers your questions. I also wanted to point out a few other ways to approach your example, realizing that it's likely a simplified version of what you're really trying to do:
As mentioned, since Chapel is designed for type-safety, even if you were to write your code simply as follows [ATO]:
config const N : int = 4;
type T = uint(32);
record MP {
var val : [0..#N] T;
}
var A : MP;
writeln(A);
you'd be guaranteed that val would be initialized to 0 because all uint(32) variables default to 0, and all arrays default to an array of their element type's default value.
Another way to express field initializations, which can often be convenient, is to write them as an initialization expression on the field itself. So, for example, if you wanted to initialize the array to be all 32-bit 1's, you could write any of the following field declarations [ATO]:
var val = [0..#N] 1: T;
var val = for i in 0..#N do 1: T;
var val: [0..#N] T = 1: T;
var val: [0..#N] T = for i in 0..#N do 1: T;
When this works, it can save the trouble of needing to write an explicit initializer altogether—e.g., perhaps only in cases where you want to pass explicit arguments to your new myType(...) calls.