Skip to content

Default constructor should have parameters for uninitialized final members. #1569

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
adrianboyko opened this issue Apr 9, 2021 · 1 comment
Labels
feature Proposed language feature that solves one or more problems

Comments

@adrianboyko
Copy link

Dart provides a default constructor for any class that does not explicitly define a constructor and those default constructors always have zero parameters. But if a class does not define an explicit constructor and it has uninitialized final members, wouldn't it be safe to assume that the programmer intends that the initializing values should be provided to the default constructor?

Example:

class Point<T extends num> {
  final T x;
  final T y;
}

Because Point<T> does not define a constructor and it has unitialized final membersx and y, the default constructor provided by Dart would be:

const Point(this.x, this.y)

In this example, the default constructor is const because all the members are final. In classes with non-final members, the default constructor would not be const.

The more uninitialized final members a class has, the more this proposal would help keep things succinct. An example from my current project:

class StatusChangeReport {
  final bool dialFrequencyChanged;
  final bool modeChanged;
  final bool dxCallChanged;
  final bool reportChanged;
  final bool txModeChanged;
  final bool txEnabledChanged;
  final bool transmittingChanged;
  final bool decodingChanged;
  final bool rxDFChanged;
  final bool txDFChanged;
  final bool deCallChanged;
  final bool deGridChanged;
  final bool dxGridChanged;
  final bool txWatchdogChanged;
  final bool subModeChanged;
  final bool fastModeChanged;
  final bool specialOpModeChanged;
  final bool freqToleranceChanged;
  final bool txRxPeriodChanged;
  final bool configNameChanged;

  // The following long/redundant constructor would no longer be required:
  // StatusChangeReport(  
    // this.dialFrequencyChanged,
    // this.modeChanged,
    // this.dxCallChanged,
    // this.reportChanged,
    // this.txModeChanged,
    // this.txEnabledChanged,
    // this.transmittingChanged,
    // this.decodingChanged,
    // this.rxDFChanged,
    // this.txDFChanged,
    // this.deCallChanged,
    // this.deGridChanged,
    // this.dxGridChanged,
    // this.txWatchdogChanged,
    // this.subModeChanged,
    // this.fastModeChanged,
    // this.specialOpModeChanged,
    // this.freqToleranceChanged,
    // this.txRxPeriodChanged,
    // this.configNameChanged);
}
@adrianboyko adrianboyko added the feature Proposed language feature that solves one or more problems label Apr 9, 2021
@mraleph
Copy link
Member

mraleph commented Apr 9, 2021

This is essentially a duplicate of #698 see the design there.

@mraleph mraleph closed this as completed Apr 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature Proposed language feature that solves one or more problems
Projects
None yet
Development

No branches or pull requests

2 participants