remove the requirement for required on nnbd arguments

[bsutton]

When defining a named argument with a non-nullable type and no default you are required to add the required keyword.

This appears to be redundant.

From the diagnostics page:

missing_default_value_for_parameter
The parameter ‘{0}’ can’t have a value of ‘null’ because of its type, but the implicit default value is ‘null’.

Description
The analyzer produces this diagnostic when an optional parameter, whether positional or named, has a potentially non-nullable type and doesn’t specify a default value. Optional parameters that have no explicit default value have an implicit default value of null. If the type of the parameter doesn’t allow the parameter to have a value of null, then the implicit default value isn’t valid.

I've identified five use patterns for named arguments:

abstract class test {
  void one({required String name});

  void two({String name = 'hi'});

  void three({String? name});

  void four({String? name = 'hi'});

  void five({required String? name});
}

The option for required with pattern five makes sense, the requirement on one appears to be redundant.

Given most of my usage of named arguments is for non-nullable types this redundant requirement is somewhat annoying.

It would appear that we could remove this requirement and provide a lint to advise that it can be removed.

I don't think this would require any migration as it simply becomes optional.

[mateusfccp]

We had a discussion about this a while ago in #878. Unfortunately, it was closed, but this makes complete sense.

[leafpetersen]

This has been very extensively discussed, both in #878 and in the original design issue thread #156 (see this comment for pointers to some of the most relevant bits). I'm going to close this out, unless there's something new to discuss here (in which case it might be better to tack it on to #878 where there's already context.

[bsutton]

Looks like it's been well discussed. I've not got anything new to add. S. Brett Sutton Noojee Contact Solutions 03 8320 8100

…

On Thu, 6 Jan 2022 at 10:26, Leaf Petersen ***@***.***> wrote: This has been very extensively discussed, both in #878 <#878> and in the original design issue thread #156 <#156> (see this comment <#878 (comment)> for pointers to some of the most relevant bits). I'm going to close this out, unless there's something new to discuss here (in which case it might be better to tack it on to #878 <#878> where there's already context. — Reply to this email directly, view it on GitHub <#2050 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAG32OHVDRZRRGUZMGVJUM3UUTHRFANCNFSM5LK5J45A> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you authored the thread.Message ID: ***@***.***>