Is there a reason to check if a non-nullable parameter is null?

I’d expect a non-nullable parameter to never ever be null. But I’ve came across this piece of code in Flutter source. The assertions (and comments) seem redundant (link to the code):

  /// Creates a route that delegates to builder callbacks.
  ///
  /// The [pageBuilder], [transitionsBuilder], [opaque], [barrierDismissible],
  /// [maintainState], and [fullscreenDialog] arguments must not be null.
  PageRouteBuilder({
    super.settings,
    required this.pageBuilder,
    this.transitionsBuilder = _defaultTransitionsBuilder,
    this.transitionDuration = const Duration(milliseconds: 300),
    this.reverseTransitionDuration = const Duration(milliseconds: 300),
    this.opaque = true,
    this.barrierDismissible = false,
    this.barrierColor,
    this.barrierLabel,
    this.maintainState = true,
    super.fullscreenDialog,
  }) : assert(pageBuilder != null),
       assert(transitionsBuilder != null),
       assert(opaque != null),
       assert(barrierDismissible != null),
       assert(maintainState != null),
       assert(fullscreenDialog != null);

I thought maybe if I pass an argument of type dynamic, I might be able to hit the asserts, but nope, the following code triggers a TypeError, not AssertionError:

final x = (() => null)();
PageRouteBuilder(
  pageBuilder: (_, __, ___) => const Placeholder(),
  opaque: x,
),

Backwards compatibility also seems out of question because AFAIK Flutter version is tied to a certain Dart version. So are these asserts (and comments) in Flutter code simply redundant, or is there a reason for them?

>Solution :

Those assertions are just a holdover from the pre-null-safety days. They’re no longer necessary, but they do no harm either.

Before null safety, named parameters could always be null, since they could be omitted. You could indicate that they were required, by adding @required before a named parameter, but even that would only yield a compiler warning. So if a required named parameter was really required, the only way to enforce that they were passed was to use such assertions, and crash the user’s program on improper usage (which is better than undefined behavior).