Inconsistent indentation of list literal between variable and getter declarations.

[lrhn]

var x = [                                       
  "long value that won't fit everywhere",       
  "long value that won't fit everywhere",       
  "long value that won't fit everywhere"        
];                                              
                                                
get y => [                                      
      "long value that won't fit everywhere",   
      "long value that won't fit everywhere",   
      "long value that won't fit everywhere"    
    ];                                          

In the var declaration, the list is indented by two, in the getter, it's indented by six.
I'd prefer if they both used the var indentation.

[matanlurey]

Same issue with map literals

[munificent]

This is (more or less) intentional. It naturally falls out of how => works, but I could have made it handle this case specifically to match variables. I didn't because I think it's useful to make these visually distinct. With a variable, the collection initializer is evaluated once. With a getter, it's evaluated each time. They really are different concepts, and I think it's OK for them to format differently.

[greglittlefield-wf]

For this case, I often find myself changing to block-style function bodies in order to increase readability, which is unfortunate (I want that nice, clean, arrow syntax 😄)

get y {
  return [                                      
    ...
  ];
}

Or, I'm temped to use comments as a hack to force the opening bracket to match the indentation of the closing one.

Myself and other members of my team think that starting the literal on the next line makes it easier to tell at a glance that the subsequent lines are within a list (when compared to the current formatting shown in the description).

get y => //
    [                                      
      ...
    ];

Same for list-returning lambdas in argument lists with trailing-comma; I would prefer for the list to not have that continuation indent, similar to list arguments. Note the difference:

new FooWidget(
  y: () => [
        ... 
      ],
  z: [
    ...
  ],
);

Any chance this issue could be revisited?

Also is that argument list case a different enough code path that I should open a separate issue for it?

[dcharkes]

This is (more or less) intentional. It naturally falls out of how => works, but I could have made it handle this case specifically to match variables. I didn't because I think it's useful to make these visually distinct. With a variable, the collection initializer is evaluated once. With a getter, it's evaluated each time. They really are different concepts, and I think it's OK for them to format differently.

I've also been running into this recently in multiple projects. One of them being Flutter where we have this pattern and are manually formatting to not use the extra indentation on =>:

  @override
  List<Source> get outputs => const <Source>[
    Source.pattern('{OUTPUT_DIR}/vm_snapshot_data'),
    Source.pattern('{OUTPUT_DIR}/isolate_snapshot_data'),
    Source.pattern('{OUTPUT_DIR}/kernel_blob.bin'),
  ];

  @override
  List<String> get depfiles => <String>[
    'flutter_assets.d',
  ];

https://github.com/flutter/flutter/blob/310e911466945aede7515d5ad288bf4048b4a601/packages/flutter_tools/lib/src/build_system/targets/common.dart#L41-L51

Any chance this issue could be revisited?

I second this.

[munificent]

Good news: The new tall style does what's being requested here. I have a PR out to add a regression test but the tall style formatter is already doing this so the bug is fixed.