How should default parameter values work with NNBD?

[leafpetersen]

We need to resolve how default parameter values should work with NNBD, for both nullably and non-nullably typed parameters.

Consider:

  void f({int x; int? y}) {...}
  void g({int x = 0; int? y = 1}) { }

Questions:

• Is the declaration of x in f an error?
  • If not, then x is effectively required
    • This in turn means that if the type of f is a subtype of the type of g, then the x parameter of g must also be treated as required, which means there's no point in giving it a default.
    • So this effectively means that there are no optional non-nullable variables
    • Unless we separately added the notion of required named parameters that are part of the type
  • If so, then optional non-nullable parameters must always have a default value
• Is passing null to the x parameter of g allowed (and interpreted the same as not passing anything)?
  • If so, then behaviorally, what's the difference between void Function({int x}) and void Function({int? x})? You can pass null to both of them.
• Does passing null to the y argument of g bind y to null (current behavior) or to 1.
  • Changing this would be a breaking change.
  • This change has been advocated for independently, since it makes forwarding work better.

cc @munificent @lrhn @eernstg

[kasperpeulen]

Does passing null to the y argument of g bind y to null (current behavior) or to 1.

In the last case, this makes y effectively non-nullable. This is problematic as you can't set a nullable parameter to null. For example, with that behavior, it becomes impossible to make a Kotlin like ‘copy’ method (in Dart often called ‘copyWith’) with nullable types. Libraries like redux would be greatly simplified if we can implement such a copy method. See also this issue for a detailed example:
#137

I think this behavior would make sense if you declare the variable non-nullable. You can then treat ‘null’ to mean, give me the default value. But if the variable is nullable, it should be possible to give null as value.

[zoechi]

What about introducing an implicit default value for every non-nullable type?

For example with a default constructor

class MyClass {
  static MyClass _default;
  factory MyClass.default() => _default ??= MyClass._default();
  MyClass._default();
}

• int: 0
• double: 0.0
• num: 0
• String: ''
• bool: false

and then either require a default value being provided for an optional parameter or a default constructor to exist for the parameter type.

[Cat-sushi]

@zoechi It is quite a easy solution, but I think those are yet other nulls error-prone.
I mean, I wonder if 0, 0.0, '' and false couldn't be sources of bugs because of mis-initialization as well as null.

[zoechi]

@Cat-sushi I thought about that as well.
There is some danger but I think it's quite convenient and usually the desired behavior, especially in UI code.

[ds84182]

I like the thought of defaults, but I think it should be opt-in. Otherwise nulls could get lost during API migrations:

library a; // using legacy types
import 'library_b.dart' as b;
void delegatesToLibraryB({int a}) => b.someFunction(a: a);

library b; // upgraded to nullable types
void someFunction({int? a}) {
  if (a == null) print("Some behavior when a is null");
}

If you start using nullable types in library a, the parameter to delegatesToLibraryB would become default-initialized to 0 instead of null. Now we just changed the behavior of all libraries that depend on library a. From just library a's perspective, this isn't an issue.

I do like the idea of default initializers, but I feel like they should be more explicit, like void func({int a: default}). This opens another can of worms for generic functions (what should void func<T>({T value: default}) do?)

[eernstg]

We could introduce default values for each type as mentioned here, and that would be helpful in order to handle declarations like T t; where T is a non-null type.

But that's a non-trivial exercise, and I think we have a rather natural set of rules already (they're the rules that just "fall out" if you consider the situation):

• It is a compile-time error for an optional positional parameter to have a non-null type and no default value.
• When a named parameter has a non-null type and no default value, it is required. That is, the rules for subtyping and for correct overrides are adjusted such that they cannot be omitted in a supertype; and the rules for invocations are adjusted such that it is an error to omit actual arguments for them.

The point is that we don't need two ways to say that an actual argument was omitted, so developers will need to make a choice: They can use a nullable type for the formal parameter (and no default, if the parameter is optional), and callers may then omit the corresponding actual argument if the parameter is optional, or they can pass null. If the formal has a non-null type then callers can't indicate that the argument is absent, because that concept is simply not supported for this parameter, but if there is a default value then callers may choose to use it by not passing anything.

The case where an optional formal parameter has a nullable type and a non-null default value may be a target for a lint. Is it ever justified? It certainly looks like a twisted setup where the designer wanted to allow the parameter to be semantically omitted (that is, to be null), and also wanted to make the syntactic omission of the corresponding actual argument mean something other than "this argument was omitted".

One case needs to be considered further: Is it possible for a type to have unknown nullability? We could get such a thing with a declaration like the following:

class A<X, Y extends num> {
  void foo({X x, Y y}) {}
}

We cannot claim that X is a non-null type if we support instantiations like A<int?, int>, and we cannot claim that it is a nullable type because we would certainly support instantiations like A<int, int>. But we could make the decision that a type whose nullability is unknown cannot be the type annotation of a named parameter with no default value (so that would be a compile-time error). In that case the developer would have to make the decision explicitly by using X? or X!, whose nullability is obviously known. Note that y is a non-problem, and it's a required named parameter, because Y is guaranteed to be a non-null type.

@leafpetersen wrote:

there are no optional non-nullable variables

In the given context I think we can conclude otherwise, using the following idea:

required named parameters that are part of the type

I'd recommend that we do this, not by adding more syntax, but simply by noting that a named parameter with no default whose type is non-null is required, and subtyping etc. must treat them as such.

Is passing null to the x parameter of g allowed (and interpreted
the same as not passing anything)?

I wouldn't want that to be allowed. It is an anomaly to allow null as an actual argument when the corresponding formal parameter cannot be given the value null. I also don't see a need to proclaim that omitting a parameter and passing null (explicitly or implicitly) is the same thing as not passing anything. It's not consistent with the actual semantics (that the default value is passed if an argument corresponding to an optional parameter is omitted), and it just creates a problem that we don't have to have.

Yes, I do recognize that a different semantics could be specified ("passing null means use the default value"), but that semantics clashes with the use of a nullable type (because then we couldn't ever pass null anyway) and actually also with the use of a non-null type (because it's yet another special case and magic effect that we can pass null to a parameter whose type is non-null, at least in the case where it has a default value). It's also a breaking change, of course.

[kasperpeulen]

The case where an optional formal parameter has a nullable type and a non-null default value may be a target for a lint. Is it ever justified? It certainly looks like a twisted setup where the designer wanted to allow the parameter to be semantically omitted (that is, to be null), and also wanted to make the syntactic omission of the corresponding actual argument mean something other than "this argument was omitted".

I think this is mistaken. Omitting the parameter, doesnt have to mean that you want it to be null. Look at the following example:

class Todo {
  final String body;
  final bool completed;
  final DateTime dueDate;

  Todo({this.body = "", this.completed = false, this.dueDate});

  Todo copy({
    String body = this.body,
    bool completed = this.completed,
    DateTime dueDate = this.dueDate,
  }) {
    return Todo(body: body, completed: completed, dueDate: dueDate);
  }
}

Note that leaving out the dueDate in the copy method here, doesnt mean, set the dueDate to null, it means, leave it as it is.

At this moment, this code doesnt work in Dart, but I heard that Dart may allow non constant default values in the future.

Im saying this, because I think it would be unwise to make omitting a variable mean the same as setting it to null, it would make it impossible to implement a copy method like I described above.

[eernstg]

@kasperpeulen wrote:

Omitting the parameter, doesnt have to mean that you want it to be null

But that wasn't what I said. We should certainly preserve the ability for an optional parameter to have a default value. If the developer who writes the method/function declaration specifies a default value for a parameter then omitting that parameter means using that default value. No problem, no confusion.

The case that I mentioned (and questioned the usefulness of) is the case where we have a (non-null) default value for a parameter and that parameter has a nullable type.

The reason why I consider this combination to be (perhaps) too twisted for its own good is that it gives the caller "two ways to omit the parameter": (1) actually omit it, in which case the body will get the specified default value, and (2) pass null (explicitly or via a computation), in which case the body will get null.

Does your example actually need the ability for dueDate to be null? If you really want that then it could be a very useful example to have in mind; I'm just noting that "two ways to omit the parameter" is more complex than "one way" (which means omitting it syntactically, which means using the default value), and I'm not quite convinced that it is helpful to have it. It would probably be addressed by a lint rather than a language error/warning, though—it may be twisted, but it's still well-defined.

That said, I still want to have support for denoting the default values of callees (such that we can write forwarding functions that preserve the default values without duplicating the code for those values, and such that we can write near-forwarders where some parameters are reordered or renamed, etc). And I'd also be quite happy about generalizing default values to allow dynamic computation. ;-)

[Hixie]

My intuition:

• passing null should mean passing null, it's not the same as omission. Passing null to a non-nullable parameter should fail.

• optional non-nullable parameters should be required to specify their default, since the default default, null, isn't valid for them.

• requiredness is orthogonal and should continue to be specified using @required.

[Hixie]

(We definitely have cases in Flutter where we want to be able to specify null explicitly, both for required arguments and for arguments with default values where the default isn't null.)

[kasperpeulen]

Does your example actually need the ability for dueDate to be null? If you really want that then it could be a very useful example to have in mind.

Indeed, I chose this example as a dueDate is a typical nullable property. Of course, the exact same problems will arise with any other nullable property and a similar implementation of the copy method.

[lrhn]

Let me make it clear that I prefer to make passing null equivalent to not passing an argument, so omitting an argument is just a shorthand for passing null. It's a much simpler model to work.

If we do that, then the function subtyping rules are simple. An optional parameter with a non-nullable type is effectively required. If it has a default value, then the parameter type for the caller becomes nullable, but internally in the function, the parameter is non-nullable.

Example:

void foo([int x = 42]) {
  int z = x;  // x not nullable;
}
void Function([int?]) bar = foo;  // Allowed because foo *does* accept `null as first argument.

Having a default value is effectively equivalent to starting the function out with:

  int x = x ?? 42;  // "Redeclares" x as non-nullable.

So, if an optional parameter's type is non-nullable on the outside, then it obviously has no default value.
This works well with subtyping because any super-type of void Function([int]) must also have a non-nullable type as first argument.

This approach does not require that the type system knows about default values because having a default value is reflected in the parameter type.
(We also don't even need optional positional parameters any more, we should be able to omit any trailing nullable positional parameter, whether declared optional or not!)

That leaves the question of what happens to:

void foo([int? x = 42]) ...

Here x is nullable on the inside and nullable on the outside, so what happens if I pass null?
I'd say that it is still replaced by the default value.

What about:

void foo<T>([T x]) ...

Here we don't know whether T is non-nullable or not without knowing whether the type argument is.
The invocation may know, but doesn't necessarily, in case the type argument is itself a type variable with a nullable bound. There will have to be a run-time check in that case, but it can still be at the call-site.

It means that you cannot pass null to a function with a default value and get a different effect than not passing an argument.
That might be a problem ... existing code does depend on this (no matter how ill-advised the design may be in my opinion).

For the copyWith methods, I'd like to make default values non-constant, so you can just write:

class Point {
  final int x, y;
  Point(this.x, this.y);
  Point copyWith({int x = this.x, int y = this.y}) => Point(x, y); 
  /* effectively the same as:
  Point copyWith({int? x, int? y} {
    x ??= this.x;  // and make x non-nullable
    y ??= this.y;  // and make x non-nullable
    return Point(x, y);
  }
  */
}

That still doesn't work for nullable fields.

class Something {
  int something;
  int? maybe;
  Something copyWith({int something = this.something, int? maybe = this.maybe}) =>
      Something()..something = something..maybe = maybe;
}

Here you can't actually change maybe to null.

Damn.

---

So, let's look at the other option: Passing null is not the same as not passing an argument.

class C<T extends int?> {
  void foo({int x, int y = 42, int? z, int? u = 42, T v, T w = 42}) => ...
  void doStuff() {
    this.foo( .... );  // which arguments are allowed here?
  }
}

We have to prohibit calling the function without a value for non-nullable non-default-valued parameters.

We should probably be disallowed from using null as an argument to a non-nullable parameter, even if it has a default value. It's omittable, not nullable.

For nullable parameters, an omitted default value is just a default value of null. Passing null does not trigger the default value (like now).

The type-variable parameters have to be handled as whatever type we think T is.
Our covariant generics may cause us to make mistakes that are caught at run-time (the T-parameters are covariant by generics), and we'll have to assume worst-case behavior otherwise. So, in doStuff, you can't pass null to v or w because T is not a super-type of Null (it's a sub-type of int?, and that is all we know).

The main problem here is that we might want to encode whether a non-nullable parameter is required in the function type. Somehow. Let's assume we write it as void Function({int x!}) (which we probably won't).

Then void Function({int? x}) <: void Function({int x}) <: void Function({int x!}).
This complicates all sub-typing and override rules. It effectively means that if a super-class method has a default value, then a sub-class override of the method must also have a default value (I'd still change the spec to allow it to be a different default value, though).

I still think the former approach is simpler, both to explain and to use, even if there are some cases that it cannot handle (because there is only one way to represent "nothing").

---

(Just for the record: A flat null is a bad idea entirely. We should have had an Option which can nest instead).

[Cat-sushi]

Let me make it clear that I prefer to make passing null equivalent to not passing an argument, so omitting an argument is just a shorthand for passing null. It's a much simpler model to work.

If we do that, then the function subtyping rules are simple. An optional parameter with a non-nullable type is effectively required. If it has a default value, then the parameter type for the caller becomes nullable, but internally in the function, the parameter is non-nullable.

I don't think so.
It's very unintuitive that parameter can be nullable for callers and non-nullable for the body at the same time.

Having a default value is effectively equivalent to starting the function out with:
int x = x ?? 42; // "Redeclares" x as non-nullable.

If so, we should do so explicitly for nullable x.
More precisely,
x ??= 42;

And I hope the system promote x to non-nullable immediately after it.