[proposal] non-nullable named parameters required by default

[pedromassango]

For example, in the code bellow I need to tell the compiler that these optional parameters are required.

  bool run({
    String taskId,
    String command,
    List<String>? args,
  }) {
    //...
  }

This code won't work in the current NNBD implementation, I need to use the required annotation.

Would be cool if the language consider every non-nullable param as required!?

So I think this:

  bool run({
    String taskId,
    String command,
    List<String>? args,
  }) {
    //...
  }

Is better than this:

  bool run({
    required String taskId,
    required String command,
    List<String>? args,
  }) {
    //...
  }

[lrhn]

One issue with that is that it might get confusing when you use a type variable.
If you write:

T foo<T>({T value}) => value;

would you then expect that parameter to be required when T is a nullable type or not?
It would probably be required as long as the type variable is potentially non-nullable, but that still makes it harder to read the code.

Another thing is that default values also make a difference. It's possible to have a required nullable parameter and an optional non-nullable parameter (if it has a default value). That again makes things harder to read if we make too many things implicit.

So, this is a case of favoring explicit over implicit because it makes the code easier to read and maintain.

[eernstg]

This is a readability/writability trade-off. It would not be hard to define and implement a rule that a named parameter of a function or a concrete method is required in the case where it has a potentially non-nullable type and no default value.

This makes it a bit easier to write, but a reader of the code would have to compute the requiredness of the parameter based on various properties. However, that computation isn't entirely trivial, and one case couldn't even be expressed any more.

An abstract method declaration can have such a parameter (potentially nullable, no default) which is not required. That is useful because an abstract method doesn't ever require a default value for any parameters, and there can be a default value specified in each implementation of the method, or the parameter could have a nullable type in some implementations:

abstract class A<X> { void foo({required X x}); }
class B1 extends A<int> { void foo({x = 42}) {}}
class B2 extends A<double> { void foo({x = 1.61803}) {}}
class B3<X> extends A<X?> { void foo({x}) {}}

The overall point is that even though the required modifier seems to be a forced choice, it is not always entirely simple to determine whether it is required, and there are even cases where you can have it, and you can omit it. So we decided to make it explicit in all cases, to improve the documentation of code properties for the readers of the code.

[rrousselGit]

If the concern is about readability vs writability, I wouldn't worry too much about the former.

This could be the job of the IDE instead of the language to fix the readability issue, as shown with the auto-generated closing tags and the UI guides

I can see a world where the required keyword would be added by the IDE.

[pedromassango]

I agree with @rrousselGit.

This is another use-case where we need to over-write the required tag even the property is not nullable. Note that the avatarUrl property is nullable so it can be optional.

class User {
  final String id;
  final String email;
  final String userName;
  final String address;
  final String phoneNumber;
  final String name;
  final String? avatarUrl;

  User({
    required this.id,
    required this.email,
    required this.userName,
    required this.address,
    required this.phoneNumber,
    required this.name,
    this.avatarUrl,
  });
}

We can think of this feature as:

• Named and nullable parameter can be optional
• Named and non-nullable parameter must be specified

[munificent]

There is a lot of discussion of this question on this issue. Some comments that might help clarify: 1, 2, 3.

[ds84182]

To be clear, the existence of required has nearly nothing to do about non-nullable parameters.

It, however, has everything to do with not being able to select a default value due to type constraints. Those constraints are... non-nullable types.

A nullable parameter can be required. A non-nullable parameter can be not required.

Argument lists today already have a virtual = null on the end of each named parameter. Tagging these as required removes the default initialization, and turns them into a different class of parameter (which we don't have today), which are required named parameters.

Being explicit about what's required makes future language developments possible, like being able to specify the default value for a type, enabling you to have the same behavior as null does for nullable types. Not being explicit means that adding a default value mechanism and having it mesh well with required parameters turns into a breaking change for anyone (Dart SDK libraries, or 3rd party libraries) to add a default, making it only useful to have for newly created classes.

Also. I firmly disagree that languages should depend on IDE tooling to be readable. Code review happens outside of IDEs, you're pushing the IDE's work onto them during review-time. The goal should be to provide readable code without IDE intervention.

[rrousselGit]

The problem is not about having the keyword or not. Its presence is necessary for many reasons.

A metaphor: required is like types. In a typed language, we should type everything.
But that does not mean we should write the type all the time.

Types have a type inference for the obvious situations. Therequired keyword needs some form of inference too.
In its current state, it only adds a huge amount of boilerplate and decreases readability.

{required int a}

is not more readable than

{int a}

Adding required in this situation only adds duplicate information, and is basically equivalent to:

MyClass value = MyClass();
// vs
var value = MyClass();

MyClass value = null;
// vs 
MyClass value

---

We could simply keep the keyword, and have it inferred when it is obvious.

This would allow:

// required
({ int value })
({ required int value })
({ required int? value })
<T>({ required T value })
<T extends Object>({ T value }) // T is non-nullable, so equivalent to {int value}

// optional
({ int? value })
({ int value = 0 })
<T>({ T? value })
<T extends Object?>({ T value }) // T is nullable, so equivalent to {int? value}

And it would not allow:

<T>({T value}) // T can be both nullable and non-nullable. Inference fails

[pedromassango]

A nullable parameter can be required. A non-nullable parameter can be not required.

Sorry I didnt get it. Why I would have a required parameter that can be null

[lrhn]

@pedromassango

Sorry I didnt get it. Why I would have a required parameter that can be null

I wouldn't necessarily recommend that, but it's definitely possible.
There can be situations where you want a parameter to be required because it is very important to the readability of the call, but you also want to allow the user to to specify a "none" value. Rather than invent a special value for "no effect", you can choose to use null for that.

You can also run into the situation with generic classes.
If you have:

class Box<T> {
  T value;
  fill({required this.value}) { // Because you *like* to write `box.fill(value: x)`
     this.value = value;
  }
}

then a Box<int?>.fill will have a required nullable parameter.

(I personally never got the idea of required named parameters at all, but other people seem to like them, mostly for readability reasons, but also for ordering).

[munificent]

A metaphor: required is like types. In a typed language, we should type everything.
But that does not mean we should write the type all the time.

This is a fair metaphor, but we have to be really careful about swinging the inference hammer. Inferring X based on the presence of Y works well when almost all readers expect that implicit magic to happen. But for any reader who doesn't expect that, they will be very surprised if they write Y and an unasked X's semantics appear in their code. Even when they do expect that to happen, they may be very unpleasantly surprised if they move X into a slightly different context where inference no longer kicks in and the Y they expected gets dropped on the floor.

Type inference is relatively safe because all users of statically-typed languages are familiar the basic mechanism of type propagation. If they write foo(bar()), they expect that the return type of bar() is implicitly checked against the parameter type of foo() even though the type flowing between those two functions is never written down. All other type inference basically builds on that intuition. (Even so, there are corners where type inference does things that unpleasantly surprise users—it's not a panacea.)

If we do "required inference", we don't have the luxury of any pre-existing user intuition we can build on. This is a relatively novel features with completely novel syntax. If we add inference, we will have to laboriously teach every Dart user about it, because they have no reason to expect it would be inferred. I personally don't think the brevity benefit of inferring required outweighs that cognitive cost.

[rrousselGit]

Would it be worth making a poll about it?
I can make one on Twitter, or the Dart team can make a large scale one too.

I do have the impression that most people are surprised that the required keyword is required. It'd be great to have numbers backing (or contradicting) that.

After all, popular languages like Typescript don't have that required keyword.

[leafpetersen]

After all, popular languages like Typescript don't have that required keyword.

Can you elaborate? My understanding (which could be wrong, I'm not a Typescript expert) is that

• Typescript has no named parameters
• For positional parameters, Typescript took a similar approach to Dart in that all parameters are required unless they are marked optional
• Unlike Dart, Typescript marks optional parameters on a per parameter basis rather than on a section.

So I don't really see the connection. It's true they don't have required named parameters (and hence don't have a required keyword). They also don't have optional named parameters. Am I missing or mis-stating a Typescript feature?

For what it's worth, we did consider marking optional parameters instead of the required ones. I believe @munificent did a corpus survey of Flutter code and found that the vast majority of named parameters were optional (correct me if I'm misremembering, Bob).

[rrousselGit]

There is technically no "named parameters", but typescript has structures and destructuring, which the community uses for it

Here's some Dart code:

void example(int a, {required String b}) {}
void example2({int? a, required String b}) {}
void example3({int a = 42}) {}

With the typescript equivalent:

function example(a: number, { b }: { b: String }) { }
function example2({ a, b }: { a: number?, b: String }) { }
function example3({ a = 42 } = {}) {}

Which allows:

example(42, {b: '42'})
example2({a: 42, b: '42'});
example3()
example3({a: 21});

The behavior is pretty close to Dart in that "named" parameters are always named and with a syntax fairly similar if we removed types.

[mateusfccp]

Common Lisp, although a great language, also has null (or NIL, in it's case).

When dealing with parameters, "normal" parameters are required by default, and named parameters (aka keyword parameters) are all optional by default, may receive a default value and optionally a binding that says if the parameter has been given.

The design works flawlessly and I don't think the usual programmer expects a named parameter to be required.

However, Common Lisp has no null-safe types, and it really don't make sense to expect a non-nullable type to be optional. A non-required parameter implies that, if I try to access this parameter from within the function I will get a default value. In this context, I can think on some possibilities:

• The default value is null. However, obviously, this can't be the case for non-nullable types.
• The default value is related to the type itself, like in C#. For example, the default int value is 0, the default bool value is false, etc.
  • This doesn't seem to be a reasonable approach, as a type default value is totally arbitrary.
  • What is a default value for a custom object (class)? C# has not non-nullable references until C# 8, when non-nullable references does not prevent compilation, only throw warnings.
• The default value is provided by the developer. This way, the behavior of a function when a given optional named argument is not passed to the function is explicit and clear to the developer.

Considering this, I think that (a) named parameters on non-nullable types should be required unless a default value is provided or (b) named parameters on non-nullable types should be required and a default value should be obligatorily provided.