bug in `dot-shorthands` experiment when using shorthands in an `enum` constructor arguments, or in a static field, or in a top-level variable

[mmcdon20]

I have been trying out the dot-shorthands experiment, and I came across this.

This occurs when you have an enum, which has another enum as a constructor parameter.

If you try to use shorthands for every enum value you will get an error on one of the values in particular (it's not always the first value).

void main() {
  A a = .a1;
  print(a);
}

enum A {
  a1(.b1), // error here
  a2(.b2),
  a3(.b3);

  const A(this.value);
  final B value;
}

enum B { b1, b2, b3 }

error:

PS C:\Users\mmcdo\AndroidStudioProjects\experiment> dart --enable-experiment=dot-shorthands bin\ab.dart
Unhandled exception:
'file:///C:/Users/mmcdo/AndroidStudioProjects/experiment/bin/ab.dart': error: bin/ab.dart:7:6: Error: This couldn't be parsed.
  a1(.b1),
     ^
#0      _delayEntrypointInvocation.<anonymous closure> (dart:isolate-patch/isolate_patch.dart:314:19)
#1      _RawReceivePort._handleMessage (dart:isolate-patch/isolate_patch.dart:193:12)   

If you add the full qualifier to whichever value the error complains about, you can use shorthands for the remaining values, and it will compile and run successfully.

void main() {
  A a = .a1;
  print(a);
}

enum A {
  a1(B.b1),
  a2(.b2),
  a3(.b3);

  const A(this.value);
  final B value;
}

enum B { b1, b2, b3 }

output:

A.a1

Dart SDK version: 3.9.0-32.0.dev (dev) (Fri Apr 18 09:03:27 2025 -0700) on "windows_x64"

[lrhn]

Could be a hint that the enum element giving the error is the one actually used by the program. Or a coincidence.

If it's not a coincidence, then either the other elements could be errors too, just hidden by tree shaking. But then it should be later in the compilation chain, not a parse error. Maybe something in constant evaluation. (But now I'm just guessing because it's fun.)

[mmcdon20]

Could be a hint that the enum element giving the error is the one actually used by the program. Or a coincidence.

If it's not a coincidence, then either the other elements could be errors too, just hidden by tree shaking. But then it should be later in the compilation chain, not a parse error. Maybe something in constant evaluation. (But now I'm just guessing because it's fun.)

You seem to be correct. After some more testing, it fails only on elements you actually use.

Edit, it appears to be any static or top-level usage of shorthands results in this behavior:

void main() {
  print(b1);
}

B b1 = .b1; // Error: This couldn't be parsed.
B b2 = .b2;
B b3 = .b3;

enum B { b1, b2, b3 }

void main() {
  print(A.b1);
}

class A {
  static B b1 = .b1; // Error: This couldn't be parsed.
  static B b2 = .b2;
  static B b3 = .b3;
}

enum B { b1, b2, b3 }

Edit again, also fails for instance variables on classes:

Fails when set directly with an initializer:

void main() {
  print(A().b1);
}

class A {
  B b1 = .b1; // Error: This couldn't be parsed.
  B b2 = .b2;
  B b3 = .b3;
}

enum B { b1, b2, b3 }

Fails if set in initializer list:

void main() {
  print(A().b1);
}

class A {
  B b1;
  B b2;
  B b3;
  A(): b1 = .b1, b2 = .b2, b3 = .b3; // Error: This couldn't be parsed.
}

enum B { b1, b2, b3 }

However, it works if used as default named value:

void main() {
  print(A().b1);
}

class A {
  B b1;
  B b2;
  B b3;
  A({this.b1 = .b1, this.b2 = .b2, this.b3 = .b3}); // Success
}

enum B { b1, b2, b3 }

And works if used as default positional value:

void main() {
  print(A().b1);
}

class A {
  B b1;
  B b2;
  B b3;
  A([this.b1 = .b1, this.b2 = .b2, this.b3 = .b3]); // Success
}

enum B { b1, b2, b3 }

[johnniwinther]

cc @kallentu

[kallentu]

Hi @mmcdon20, thanks for filing out this issue. It's great to hear that you've been trying out the dot shorthands feature and I appreciate the feedback a lot.

For this bug, I've confirmed with a couple tests that all the cases here were due to an extra token I added and planned on removing (and could only fix when we were far into the analyzer implementation). Luckily, we just got this fix in recently: 4ddb83e . So everything here should be working as expected now.

However, I've added a language test (https://dart-review.googlesource.com/c/sdk/+/424660) to make sure we capture all the testing in this issue and that we don't have any further regressions.

I'll close out this issue now, but if I missed anything, feel free to reopen it and I'll follow up.

[mmcdon20]

Your test for nested enum is not using the shorthand.

enum NestedEnum {
  red(Color.red),
  blue(Color.blue); // should be blue(.blue)

  const NestedEnum(this.color);
  final Color color;
}

[kallentu]

Your test for nested enum is not using the shorthand.

Good catch. I was testing around and forgot to remove the type. Should be fixed now

[mmcdon20]

I don't yet have the version with the fix, but I have a few more test cases you can use.

It appears to also fail on functions arrow syntax =>, but not function body syntax {}.

void main() {
  print(getterArrow); // Error: This couldn't be parsed.
  print(getterBody); // Success
  print(Methods().getterArrow); // Error: This couldn't be parsed.
  print(Methods().getterBody); // Success
  print(Methods.getterArrowStatic); // Error: This couldn't be parsed.
  print(Methods.getterBodyStatic); // Success
}

enum Color { red, blue, green }

Color get getterArrow => .red;
Color get getterBody { return .red; }

class Methods {
  static Color get getterArrowStatic => .red;
  static Color get getterBodyStatic { return .red; }
  Color get getterArrow => .red;
  Color get getterBody { return .red; } 
}

Also anonymous functions fail in both arrow and body variants:

void main() {
  print(anonymousFunctionArrow()); // Error: This couldn't be parsed.
  print(anonymousFunctionBody()); // Error: This couldn't be parsed.
}

enum Color { red, blue, green }

Color Function() anonymousFunctionArrow = () => .red;
Color Function() anonymousFunctionBody = () { return .red; };

[mmcdon20]

I have tried the latest dart version, and all of the above examples seem to be working as expected now.

[kallentu]

I've added your test cases above. Thanks for making them and checking that they work on the newest version.