Sdk: Allow required named parameters

[DartBot]

_This issue was originally filed by [e-mail]_

---

I really like the named parameters feature in dart, but was disappointed that it can only be used if the parameter is optional. Is there any reason why it is not allowed in general?

It is really usefull to write

  flipFlags(on: true, up: false, hidden: true);,

even if the parameters were not optional. I some cases, i dont want to use optional parameters but still like to call a function with named parameters.

[dgrove]

_Set owner to @gbracha._
_Removed Type-Defect label._
_Added Type-Enhancement, Area-Language, Triaged labels._

[gbracha]

We've considered this quite recently and decided against it. In principle, making named parameters and optionality orthogonal is elegant. However, the interactions between the various situations (named, optional) add complexity to the runtime, and this particular situation doesn't strike us as very compelling. We are looking at allowing optional positional parameters, which does seem to have more justification.

I'm renaming the bug so it is clear what it is about.

---

_Added NotPlanned label._
_Changed the title to: "Allow required named parameters"._

[DartBot]

_This comment was originally written by [e-mail]_

---

optional positional parameters seems good enough. The advantage of this is mainly that it makes the code more readable, rather than "you dont need to guess the position of params". It should be easily implementable by just ignoring the names.

[DartBot]

_This comment was originally written by [e-mail]_

---

I have (in Java) preferred constructors (over setters) for initializing "required" fields. The problem is that when the list of constructor args gets really long, the code becomes less readable:

ProductCatalog pc = new ProductCatalog(dep1,dep2,dep3,dep4);

The whole reason i prefer constructor initialization is so that the compiler/ide can make sure i didn't forget a required param.

Does Dart address this is some other way?

[gbracha]

Regarding comment 4: The forums are better palce for this question, but here goes:

Optional parameters may be helpful here, as you may be able to provide reasonable defaults in some cases and reduce the need for of long lists of actual parameters.

Also, because dart constructors do not undermine encapsulation the way traditional constructors do, using them is not an antipattern as it is in Java (regardless of how popular it may be).

The use of getters can be helpful as well, as you can initialize such fields lazily with much less syntactic overhead than in Java.

[DartBot]

_This comment was originally written by @seaneagan_

---

One thing this would help with is initially making args required, and then once you find a good default value, changing them to optional.

[filiph]

It is worth noting that the meta package (maintained by the Dart Team) has, among other things, the @required annotation.

To get to the https://github.com/dart-lang/sdk/issues/4188#issue-84512696 use case, one would simply write.

import 'package:meta/meta.dart';

void flipFlags({@required bool on, @required bool up, @required bool hidden}) {
  // ...
}

The analyzer understands these annotations and will provide warnings at call site. You can even give reason, like @required('The callback needs to be set').

We might want to give this package a bit more visibility in our docs. The package is version 1.0.2 as of August 16.

[svenjacobs]

Too bad that the decision was made against required named parameters :( I believe named parameters help in structuring and documenting source code as well as preventing subtle bugs. Imagine for instance a function with more than one or two parameters where all are of the same type. You could easily mix up the order of the parameters w/o named parameters. But since each named parameter in Dart is optional the developer has to make sure that required parameters have been passed, possibly throwing an exception when one is missing.

The @required annotation helps but a native support of required named parameters is greatly appreciated.

[lukepighetti]

Make named parameters required by default, make them optional by wrapping them in []. Works exactly like un-named parameters. But allow someone to wrap multiple at a time

foo({ String text, [int views, List<String> links] }){
  print('$views and $links are optional')
}

[WillemMali]

I'm requesting this issue to be reopened.

We've considered this quite recently and decided against it. In principle, making named parameters and optionality orthogonal is elegant. However, the interactions between the various situations (named, optional) add complexity to the runtime, and this particular situation doesn't strike us as very compelling. We are looking at allowing optional positional parameters, which does seem to have more justification.

Most runtime errors I encounter in Flutter are caused by missing required named parameters, which are then caught by assertions. This would be eased if Flutter used the meta package instead of assertions.

It's mainly a bother that the @required annotation requires an import (in every file I use it in); perhaps this annotation could be made part of the language, or globally enabled via pubspec.yaml?

[eernstg]

In general, language issues are now handled in the 'language' repository. The topic of this issue is alive over there, e.g., https://github.com/dart-lang/language/issues/156.