There are hundreds of these after an upgrade. Is there a faster way?

Not automatically: dart fix --apply won’t clear these. The IDE quick fix can make one parameter nullable at a time, but each parameter still needs a decision (required, default or nullable). Starting with shared widgets clears the most errors per change.

Does a positional parameter in square brackets work the same way?

Yes. [int count] is optional too, so it needs a default ([int count = 0]), a nullable type ([int? count]), or to become a normal required positional parameter.

Can you fix it for me?

If one bug is the whole problem, the App Fix Ticket covers it: a written diagnosis first, then the fix. If the app has more going on, the Launch Check is a written check of the whole app. Each issue found is rated critical, high, medium or low, with where it is and how it was confirmed. No issues worth fixing, no charge. If the Launch Check finds nothing rated medium or higher, Simon refunds the full $450. You keep the report either way. This applies to the first 10 Launch Checks bought after October 30, 2026.

Flutter “Parameter Can’t Have a Value of Null”: Fix

Dart null safety errorFlutter: “The parameter ‘…’ can’t have a value of ‘null’ because of its type, but the implicit default value is ‘null’”

Dart reports The parameter ‘title’ can’t have a value of ‘null’ because of its type, but the implicit default value is ‘null’. An optional parameter (named, in curly braces, or positional, in square brackets) has a non-nullable type and no default value, so leaving it out would make it null. It shows up all over code written before null safety, such as widget constructors like MyCard({this.title}).

Short answer

Decide what the parameter means. If callers must always pass it, mark it required (required this.title). If it has a sensible fallback, give it a default value. If “not given” is a real state, make the type nullable (String? title) and handle null where it is used. The old @required annotation doesn’t count; use the required keyword.

Why the parameter could be null, and the fix

01
A widget constructor from before null safety
“If the parameter can't be null, then either provide a default value” Dart, missing_default_value_for_parameter
Named parameters are optional unless marked required. A field like final String title with a constructor parameter {this.title} has no value when the caller leaves it out.
```
class MyCard extends StatelessWidget {
  const MyCard({super.key, required this.title, this.subtitle, this.elevation = 1});

  final String title;      // must be passed
  final String? subtitle;  // may be missing
  final double elevation;  // has a default
}
```
02
@required instead of required
Code migrated from older Flutter often still has @required from package:meta. With null safety, only the required keyword makes a named parameter mandatory.
```
// before
MyCard({@required this.title});

// after
MyCard({required this.title});
```
03
Making it nullable without handling null
String? silences the error, but every use then has to deal with null, for example with ?? or an if check. Don’t add ! to make it compile, which turns the compile error into a runtime crash.
```
final String? subtitle;

Text(subtitle ?? 'No subtitle')
```

Checked against the vendor’s docs on November 8, 2026: Dart diagnostics: missing_default_value_for_parameter; Dart: Understanding null safety.

Rather hand it over?

Fixed scope, fixed price, paid upfront. The work happens in writing; no call needed.

Dart null safety errorFlutter: “The parameter ‘…’ can’t have a value of ‘null’ because of its type, but the implicit default value is ‘null’”

Why the parameter could be null, and the fix

A widget constructor from before null safety

@required instead of required

Making it nullable without handling null

Rather hand it over?

More on this error

Describe it and get a written quote