Hint to me when I have nullable fields in an object

[sethladd]

The following construct should be avoided:

class Thing {
  double x;
  double y;
  double z;

  Thing(this.x, this.y, this.z);
  Thing.empty() {}
}

Issues are:

• x, y, and z could become null if Thing is constructed via empty().

The VM has a hard time optimizing fields that could be double or null. dart2js has a hard time optimizing field access that could be null.

Of course, I could set x,y,z to final. Or, I could eliminate empty() constructor.

[alan-knight]

I'm curious what the story for suppressing lint warnings is going to be. This seems like a rule that's likely to give large numbers of warnings for things that are valid. For example, if I have Thing with no empty() constructor I might very well end up with a ThingBuilder which would have those warnings. Am I going to be able to indicate that particular uses are fine, or am I going to have to turn the rule off globally or else learn to ignore those warnings?

[sethladd]

Good question! I don't know how one opts-into lints, especially ones that could have performance ramifications. Maybe the user makes an explicit request: "Show me lints that make the VM and dart2js happy"

[pq]

Great question @alan-knight. There's the beginning of a conversation started over on #57153 but nothing is settled. Feel free to chime in!

@sethladd : wanna take a stab at a short description? For more context, I threw together some basic lint writing guidelines here. (Thanks for the nudge! 👍 )

[srawlins]

Superseded by null safety.