Addressing user expectations around null-aware elements

[chloestefantsova]

Consider the following program.

class A {
  int? get x {
    print("Getter 'x' called.");
    return 0;
  }

  foo() {
    return [0, if (x != null) x!, 1];
  }
}

main() {
  new A().foo();
}

In that program, replacing if (x != null) x! with ?x changes the observable behavior. In the former case it will print the line Getter 'x' called. twice, and in the latter — once. This is the reason behind the linter not offering such a rewrite when getters are tested for being null.

However, as hinted by #61122, it might go against the intuition of the programmer, since in practice many getters are stable and don't have any side effects.

Should our tooling account for such user expectations and possibly provide a hint or address it in any other way?

[chloestefantsova]

/cc @bwilkerson

[FMorschel]

From @bwilkerson's comment:

My personal line is drawn at getters only, since they usually shouldn't have side-effects.

I can live with that.

We were discussing whether the Remove unused local variable should remove the full statement when we hit getters.

I'd say we should probably be consistent in all our lints/quick-fixes and have a single place to reference when looking at these cases.

[bwilkerson]

Thanks for raising the question. I don't think it has a clear and obvious answer.

Yes, we definitely need to be consistent.

In general, we don't restrict the code actions to only those that preserve semantics exactly. Doing so would prevent us from providing lots of useful aids to users. So I think the question is how likely it is that users will be confused by this behavior.

• As far as I know, the tooling for most other languages also doesn't prevent code actions from changing semantics.
• This isn't the only code action we have that changes semantics, and in some cases doing so is exactly the purpose of the action.
• I suspect that most users expect getters to have no side-effects, and hence write them to have no side effects. I know that many users don't even think about getters when referencing a field and are confused by the fact that our tools aren't consistent with their mental model. Inference is one prime example.

Given all of that, I'm guessing that most of the time users won't even be aware that there's a change in semantics.

That doesn't mean that it won't be surprising when there is a change in semantics. In fact it probably argues exactly the opposite: because users aren't considering the possibility that getters can have side-effects the difference in semantics might be hard to understand.

The biggest argument against attempting to make this clear in the UI is that it's so unlikely to happen that it might cause more confusion to users (in total) to have it brought up at all. I don't know that I have a definitive answer, but I'm definitely leaning toward saying that we should treat getters the way users think of them and allow the code action without any kind of warning.

Should our tooling account for such user expectations and possibly provide a hint or address it in any other way?

The only way available to us to let users know that a code action like this might not preserve the semantics would be to append something to the menu label. For example, the menu label could be changed to something like

Convert to use '?' (might change semantics)

We could limit this to the cases where there's a getter involved so that it isn't displayed when we know it can't change the semantics, but we'd need to apply the change to every code action for which it's true. Even so, I'm concerned that this would

• make users less confident in using our tools
• make the UI more noisy
• bring little or no value