Should the compiler warn about param fields that are not given an explicit default value? about chapel

[lydia-duncan]

This is an intriguing idea. I think as long as we add a way to explicitly silence the warning (like an attribute) at the same time, such warnings would be useful

[mppf]

But it also made me want to check whether you're proposing eliminating defaults for all params, or just fields.

I'm only proposing removing the default for param fields in user-defined initializers here.

Presumably the second case would still work, and we'd want it to, and the first would still be an error, just a different kind of error? So what inconsistency is getting resolved?

Hmm. I think you're right, at least re-reading my comment leaves me wondering the same thing.

So what's the inconsistency? It's that we consider param p: int to have a default in some initializer settings but not others:

• it does not have a default as a formal for the type constructor
• it does not have a default as a formal for the compiler-generated default initializer
• it does have a default in a user-defined initializer.

If we make it not have a default for the user-defined initializer, these become consistent; we can say that a field param p: int is not considered to have a default. That would make it more consistent with type fields, which appeals to me because I consider param to be closer to type than to var/const/etc.

[bradcray]

Yeah, I agree we'd want a way to opt-out (as with all warnings).

[mppf]

IMO it does not make sense to have a param field use a default value when one is not specified (i.e., 0 for integers). Adding a warning for the initializer above that does not initialize rank would certainly be OK with me, but I have a slight preference for going further and making this case an error.

Today, param fields don't work the same as if they have the zero default value:

record R {
  param p: int;
}

var x: R; // warning: please use '?' when declaring a variable with generic type
          // error: cannot default-initialize a variable with generic type
writeln(x);

record R {
  param p: int = 0;
}

var x: R;   // OK
writeln(x); // prints ()

Making it the initializer not setting this.rank into an error would resolve this inconsistency.

On this point, the spec says this:

In order to support productive and elegant initializers, the language allows field initializations to be omitted if the field has a type or if the field has an initialization expression. The compiler will insert initialization statements for such fields based on their types and default values.

So, the spec matches the current behavior. However, IMO, the "field has a type" rule should only apply to non-param non-type fields.

[bradcray]

@mppf: I think I'm open to your stronger proposal, though I'm not quite understanding your statement that the change would resolve the inconsistency (or maybe I don't understand what the inconsistency is?). Presumably the second case would still work, and we'd want it to, and the first would still be an error, just a different kind of error? So what inconsistency is getting resolved?

The only slight hesitancy I have about the approach is that I like that non-field param count: int; or config param count: int; default to 0 (for consistency with var and const), so am slightly uneasy about adding an inconsistency between fields and non-fields in this regard. But I think I'm more worried about the confusion I hit than I am about that inconsistency.

But it also made me want to check whether you're proposing eliminating defaults for all params, or just fields.