[analyzer] No error in case of `?.` in a constant expression

[sgrekhov]

With the recent change the following code produces and error in CFE but no error in the analyzer.

const String? c1 = null;
const int? c2 = c1 == null ? null : c1?.length;  // Error: Null-aware property access can't be used in a constant expression.

main() {
  print(c2);
}

@eernstg please confirm that there should be an analyzer error as well.

Dart SDK version: 3.9.0-edge.cddee72854b2c735148751f08eb0cc51d05854c9 (main) (Mon May 5 01:50:25 2025 -0700) on "linux_x64"

[eernstg]

Yes, "this is not a constant expression" is an error for any static analysis, analyzer or CFE, when a constant expression is required.

[FMorschel]

Interestingly:

const String? foo = null;
const int? bar = foo == null ? 0 : foo?.length; // Nothing
const int? baz = foo?.length; // const_eval_property_access

[FMorschel]

Also, this too has no analyzer warning but doesn't compile:

class A {
  const A(String? foo, String? bar) : assert(foo?.length != foo?.length);
}

[eernstg]

The plan for now is to revert the change in behavior and then discuss in the language team whether we should add s?.length to the set of constant expressions (with suitable extra requirements about potentially constant expressions and evaluation results, as usual). So we should probably block tests that depend on this decision.

[johnniwinther]

The implementations inadvertently supported some parts of this, so we ended up allowing it in general. The change landed in https://dart-review.googlesource.com/c/sdk/+/429921

[eernstg]

Right, and the language specification has been updated to include e?.length as a constant expression, with some extra conditions as usual.

[eernstg]

I think we can close this: The specification and the implementations have been updated. @johnniwinther, please reopen if you disagree.