convert to named parameter quick fix: Named parameters can't start with an underscore.

[stephane-archer]

class _LutPreviewImagesState {
  final List<LutPreviewResult> _lutImages;
  final StreamSubscription<LutPreviewResult>? _steamSubscription;
  final Future<PreviewManager> previewManager;

  const _LutPreviewImagesState(
      this._lutImages, this._steamSubscription, this.previewManager);

}

convert to named parameter quick fix:

class _LutPreviewImagesState {
  final List<LutPreviewResult> _lutImages;
  final StreamSubscription<LutPreviewResult>? _steamSubscription;
  final Future<PreviewManager> previewManager;

  const _LutPreviewImagesState(
      {required this._lutImages,
      required this._steamSubscription,
      required this.previewManager});

Named parameters can't start with an underscore.

[bwilkerson]

Thanks! You're right, we shouldn't be suggesting that change.

[stephane-archer]

@bwilkerson it would be better to remove the _ from the name

I think the operation is useful, just the output is not correct in this case

[bwilkerson]

Our current design approach would be to not make changes that a reasonable user might not expect, but to provide a sequence of operations where the result of each step is unambiguous.

I think it could be surprising for the name to be changed as a result of asking for it to be converted to a named parameter. But there's a two step path to doing the same thing which is to first rename the parameter and then convert it to be a named parameter.

[stephane-archer]

@bwilkerson I see your point but it might not be obvious for the user that the operation is not available because of the _ in the name with this approach.

You can preserve the name of the member variable and just change the named parameters to match the constraints using initiaser list.

I think the behavior would be similar to the one observed when you rename a member variable when adding an _

[bwilkerson]

... it might not be obvious for the user that the operation is not available because of the _ in the name ...

That's true.

You can preserve the name of the member variable and just change the named parameters to match the constraints using initiaser list.

That's an interesting idea. I'd be fine with that, assuming I have the right understanding of your suggestion, because the effects are semantic preserving.

So to check my understanding, given

class C {
  int _f;
  C(this._f);
}

the refactoring would produce

class C {
  int _f;
  C((required int f}) : _f = f;
}

[FMorschel]

Today if we have:

class C {
  int f;
  C({this.f});
}

And we rename f to _f:

class C {
  int _f;
  C({int f}) : _f = f;
}

So we'd be coherent here too.

PS: Beware that you currently need to rename the field itself (this issue #52305 is tracking renaming on the parameter to work the same way).

[stephane-archer]

@bwilkerson Yes, I think we are on the same page.

[FMorschel]

This may affect DeCo (I assume), so maybe tag this too @bwilkerson?