`dart --enable-experiment=constructor-tearoffs format` doesn't

[eernstg]

The following program causes dart format (from ef8add0) to request the experiment which is actually enabled:

X id<X>(X x) => x;
void main() => id<int>;

Here is the response from dart --enable-experiment=constructor-tearoffs format n035.dart where n035.dart is the name of the file storing the above library:

> head_test_dart --enable-experiment=constructor-tearoffs format n035.dart
Could not format because the source could not be parsed:

line 2, column 18 of n035.dart: This requires the 'constructor-tearoffs' language feature to be enabled.
  ╷
2 │ void main() => id<int>;
  │                  ^^^^^
  ╵
Formatted no files in 0.13 seconds.

It makes sense that this feature may not yet be implemented, but it is surprising that it causes the requires .. enabled message to be emitted.

Trying out other experiments (including some strings that aren't the name of any experiment), it seems likely that the --enable-experiment=... is ignored completely. Is that intended? (It could be intended that the formatter only supports one language version, but it would then still be helpful to handle the --enable-experiment option explicitly).

[srawlins]

CC @devoncarew

[devoncarew]

I don't believe that we pass the experiments flag info to the format command in the dartdev implementation. I'm not sure what the best behavior here is in any case - I'm not sure that users would expect to have to opt the format command into a language experiment. Perhaps format should just to very permissive - act as if all experiments are enabled?

cc @bkonyi @munificent

[bkonyi]

Yeah, there's no --enable-experiment flag for dart format in the CLI. If the formatter requires experiments to be explicitly enabled for formatting, we should add --enable-experiment as an option.

[munificent]

Trying out other experiments (including some strings that aren't the name of any experiment), it seems likely that the --enable-experiment=... is ignored completely. Is that intended?

Yes, this is expected. The way it works is that the formatter silently enables all experiments. The idea is that it can format the superset of all possible Dart language versions. That way it doesn't have to worry about looking up package configs to figure out what language version each file has. In theory, this could cause problems if we were to reinterpret some existing syntax in a different way in Dart. In practice, it hasn't been an issue so far.

The way I do this mechanically is I just hardcode a language version and all the experiment flags and then try to keep that up to date. I'll add constructor tear-offs to that (and add tests) shortly.

[munificent]

Fix out: dart-lang/dart_style#1047

[eernstg]

Thanks, that makes sense!

[munificent]

I have landed a fix for this on the master branch of dart_style, but I'm not currently planning to immediately roll that into the SDK unless someone wants me to. Is it useful to kick out a release right now?

[devoncarew]

I don't believe we plan to land any user facing tearoff work until the next beta (after this upcoming stable branch), so I don't believe there's a need to immediately land that change in the SDK.

[munificent]

This is in the SDK now: https://dart-review.googlesource.com/c/sdk/+/210285