16857, “bradcray”, “Should Chapel support an ‘init=’ operator?”, “2020-12-11T19:37:26Z”
Chapel currently uses = both for initialization, as in:
var x: t = 10;
and in assignment, as in:
x = 20;
where the former will call the init= method on t and the latter will call the = overload for t, int. Historically, the fact that these two use the same syntax has not been a big deal since, syntactically, it was fairly easy to distinguish between the two. However, now that we have split initialization, it can sometimes be less clear. For example:
var x: t;
... // some more code is here
x = 10; // is this an assignment or an initialization?
This has made me generally wonder whether we should support an init= operator which could be used by a user who wanted to distinguish these cases for clarity / to have the compiler check that their code is doing what they thought. That is, if I intended for the x=10; to be an initialization in the previous example, I could write:
var x: t;
...
x init= 10;
as a means of clarifying my intent to the compiler and reader. If the code in “…” had actually forced a default initialization of x (such that in the previous version x=10; had actually been an assignment), the compiler would complain on the x init= 10; line, saying something like 'x' can't be initialized here because it's already been initialized on line n.
Note that I’m not proposing that we require split initialization cases to use init= rather than =. I’d also imagine that we would probably permit someone to write:
var x: t init= 10;
even though there’s no real need or benefit to doing so.
Since init= is already a reserved token, this doesn’t require reserving any new keywords which is nice, and while the feature is not strictly required (in that we’re living without it today), it seems like it could lead to more readable code when used.