Exclude {Key? key} from `always_put_required_named_parameters_first`

[esenmx]

Since Flutter source code full of {Key? key, required ...} constructors, it would be better excluding this specific case.

Flutter example:

const Padding({
    Key? key,
    required this.padding,
    Widget? child,
  }) : assert(padding != null),
       super(key: key, child: child);

[pq]

/fyi @goderbauer

[goderbauer]

I am not sure if it's worth making an exception for this. The always_put_required_named_parameters_first lint doesn't seem particularly useful for flutter code...

[NANASHI0X74]

maybe the lint rule could instead allow grouping super initializing parameters now that that feature has landed in dart, but still ensuring that required super parameters are sorted before other super parameters? i.e.

class A{
  A({required this.a, this.b = 'default'});
  final String a, b;
}

class B extends A{
  B({required super.a, super.b, required this.c});
  final String c;
}

currently, the lint rule would require to reorder the named parameters in B's constructor like this:

B({required super.a, required this.c, super.b});

which in this case inhibits grouping all super parameters together.

I'd argue it's nicer to read the constructor when the super parameters aren't mixed with other parameters, or is that just me? If more people share this opinion it might make sense also to add a linter rule that enforces super parameters to appear before other parameters