NNBD_TOP_MERGE produces new and some times less useful member signatures

[eernstg]

The nnbd spec includes the following case in the definition of NNBD_TOP_MERGE:

NNBD_TOP_MERGE(Object?, void) = void

Together with other similar cases, this implies that if we describe NNBD_TOP_MERGE as a max operation on a partial order, the underlying ordering (let's denote it by <) is dynamic < Object? < void. (It is not important that we don't actually have a partial order, we certainly have a total order on subsets like {void, dynamic, Object?}.)

This differs from earlier discussions where we have assumed that the underlying order was Object? < dynamic < void, but we cannot compare directly because NNBD_TOP_MERGE is applied in a manner which is variance-agnostic (that is: we do the same thing to a function return type and a function parameter, whereas variance would normally dictate that we do "opposite" things in the two cases).

The computation that yields a member signature for m in a class C based on several "nearly identical" ones for m inherited from the direct superinterfaces C will use NNBD_TOP_MERGE to decide on parameter types and return types, so this matters for the interface of every class.

A new thing (which is very nice, but that we didn't dare to do for Dart 2) is that interface specificity with NNBD will be symmetric and computed (so we can combine the member signatures from two different superinterfaces and come up with a member signature which doesn't occur anywhere in the program).

However, this ordering will create some situations that we may not intend:

class DontCare {}

abstract class A1 {
  void get m1;
  DontCare m2(void _);
}

abstract class A2 {
  Object? get m1;
  DontCare m2(Object? _);
}

abstract class A2 {
  dynamic get m1;
  DontCare m2(dynamic _);
}

abstract class B implements A1, A2, A3 {
  // Interface of B:
  //     void get m1;
  //     DontCare m2(void _);
}

Let us consider a covariant position in the member signature first (say, a getter return type):

Dart has previously always given the type void a treatment which is reasonably approximated by saying that it is the ultimate top type. For instance, it was allowed to override a method returning void by a method returning T for any type T, but not vice versa; the rationale was that it is safe to return any object if callers either expect an object of that type (when the static type is T) or if they expect that the method doesn't return anything of interest (when the static type is void). In Dart 2 we just consider the subtype relationship and allow Object and dynamic to override void and vice versa. However, this rule will now choose void for the member signature also in cases where it overrides Object? or dynamic in some superinterfaces.

This may break existing code because a some expressions will now have type void, whereas the current approach (which involves the ordering of declarations as well) could have yielded the type dynamic or Object (now spelled Object?).

With contravariant positions (say, a formal parameter type) we get a similar conflict with previous typing results:

The method m2 in the example gets a parameter type of void. This does not create so many problems, because call sites can pass any object to a parameter of type void, just like they can do that with Object? and dynamic. However, it may create problems for type inference:

void f(List<void> _) {}

void main() {
  f([1]..[0].isEven); // Error: Expression of type 'void' can't be used.
}

Also, it will break implementations where the combined member signature is used to infer the type annotations of parameters: The body of m2 in a subtype of B will suddenly have compile-time errors, because it uses its parameter.

So it is probably not very pragmatic to have these "avoidable void types" in member signatures, neither in covariant nor in contravariant positions.

So I'd recommend that we consider a different ordering: void < dynamic < Object?.

This might look surprising, but given that this mechanism is variance agnostic there is no need to align the ordering with the subtype relationship (or any intuition about subtyping or related concepts); for instance, we could just as well consider the ordering to be reversed: Object? < dynamic < void. In any case, it means that NNBD_TOP_MERGE(Object?, void) = Object? and so on.

If we change NNBD_TOP_MERGE accordingly that then we'd have the following outcome:

abstract class B implements A1, A2, A3 {
  // Interface of B:
  //     Object? get m1;
  //     DontCare m2(Object? _);
}

Intuitively, we would then say the following: This signature type (return type or parameter type) is a top type that may have some ambiguity. If there is any Object? then it wins; otherwise, if there's any dynamic then it wins; otherwise it is all void and we keep that.

@leafpetersen, @lrhn, @munificent, WDYT?

[lrhn]

For get m1, it seems correct that we might return something, but we don't know what. We may pass the B instance it to someone who ignores the result of m1 (expection A1), but also to someone who doesn't (expecting A2 or A3), so we cannot assume the result is ignored.

However, for m2(...), we implement a method which may be called with a value that should be ignored, so void would be more correct there. As you say, we are not contravariant on parameters (why not?), and we never got "void preservation step 2", so nothing prevents this. So if we need to do the same thing for m1 and m2, then it should be Object? here too.

So, which one is more annoying and/or incorrect: Using void for m1 or Object? for m2?

The m1 is annoying, but easily overwritten by adding a getter to B.
The m2 is potentially incorrect (but we don't prevent that if you write m2(Object?) directly in B, so it's not like we really care).

I'm not sure what I prefer (but I'd go for prober co/contra-variance in the resolution if possible).

[leafpetersen]

I'm not sure I really see a convincing argument for changing this or making it more complex. My reasoning in the ordering was to always choose the least permissive top type of the two options. This means that nobody is ever surprised by getting a more permissive type than they thought they were getting. If the type the get is "under-permissive", then they can always choose to add an explicit override to mediate the type.

[lrhn]

The problem with choosing the least permissive type in a contravariant position is that that makes the function callable with an argument that is supposed to be handled in the least permissive way, but maybe it isn't.
That's because the implementation doesn't necessarily match the unified type, so if you pass a void Function(int) to a member with that signature , but where the implementation is actually void foo(Object? Function int()), then nothing protects it from using the void value.
(Then again, there are so many ways to use a void value that it should probably not be considered a protection at all).

Could we instead always use the type of the concrete implementation of the member, if that type is among the most specific ones? (If it is not, the class must be abstract).

That won't help for pure interface merging, but then there is also not a problem with an implementation not matching the resulting type.

[leafpetersen]

The problem with choosing the least permissive type in a contravariant position is that that makes the function callable with an argument that is supposed to be handled in the least permissive way, but maybe it isn't.

I don't understand this. I don't think the result of NNBD_TOP_MERGE affects callability at all.

This program has no errors or warnings:

class A {
  void foo(Object Function() f) {}
  void bar(void Function() f) {}
  void baz(dynamic Function() f) {}
}

void main() {
  void f() {};
  new A().foo(f);
  new A().bar(f);
  new A().baz(f);
}

So not matter what we choose here, the callability is the same. The only difference is in what signatures the user sees, and what types are used for inference.

[eernstg]

@leafpetersen wrote:

I'm not sure I really see a convincing argument for changing this or making it more complex

It wouldn't be more complex to just use the ordering void < dynamic < Object?, which corresponds to the ordering that we have otherwise used in many discussions (we've usually stated it is Object? < dynamic < void, but it is inverted here because NNBD_TOP_MERGE is similar to a greatest lower bound, and those other discussions used a least upper bound).

The problem I see is that we are breaking existing code for no good reason at all: An expression which had some non-void top type previously may now get the type void. So any attempt to use the returned value may now be an error (or it is allowed in a context like var y = x.foo(), but y now gets the type void, so usages of y may now be an error).

abstract class A1 {
  Object? get m1;
}

abstract class A2 {
  dynamic get m1;
}

abstract class A3 {
  void get m1;
}

abstract class B implements A1, A2, A3 {}

void main() {
  B b = ...;
  var x = b.m1; // Pre-nnbd type of `x` is `Object` (now `Object?`), nnbd type is `void`.
  ...
  print(x); // Breaks when we migrate: "`x` can't be used!".
}

I agree that it makes sense to take the opportunity with nnbd to make typing more consistently biased toward statically checked member invocations, so it's fine to let Object? prevail when it occurs together with dynamic.

But I think it's a gratuitously breaking change if we let void prevail over everything else. It is particularly breaking because we will now potentially fetch that void return type from any superinterface, not just the textually first one that has a most-specific function type for the given member.

Of course, the same phenomenon occurs with composite types: If are merging return types List<Object?>, List<dynamic>, and List<void>, we'll get List<void>.

There is also a semantic argument: We used to say that a void return type can be overridden by any other type T, because it is safe to say "don't use this value" for any T. However, it is unsafe in a similar sense to let a void return type override another type, say Object?, because this means that the static type of the call can be Object?, but the actual method implementation that runs declares that it returns void; so we shouldn't use the returned value, but the type system fails to enforce that requirement. So void is semantically a natural supertype of Object? and dynamic, and the proposed NNBD_TOP_MERGE makes void a subtype of both (because it is similar to a greatest lower bound for the case that matters the most for clients: a covariant position).

I really don't think we are helping anyone by letting void play the role as a subtype of Object? and dynamic.

[lrhn]

I'm talking about void-soundness, not callability. That is, whether you should call, not whether you can.

If a class implements the interface method int foo(void x); then it can be cast to an interface where it has that type. Someone can call it with an argument which is expected to be ignored. But if the class also implements another interface method int foo(Object? x), and the top-merge algorithm unifies the two to int foo(Object? x), then the person implementing foo has no clue that they shouldn't be using the argument - even though someone might actually call them with such an argument.

I know that void typing is neither safe nor sound, and this is probably not a big issue.
And that anyone can explicitly write dynamic or Object? and dodge the void bullet anyway, so it's not much protection.
So, maybe not an issue.

For the return value, I think we should consider void the least precise type, and dynamic/Object? more precise, and pick the most precise type among the candidates.

Whether we consider dynamic or Object? more precise is a tradeoff between not breaking existing code and not introducing implicit dynamic if avoidable.

If we always choose dynamic, then all existing code will keep working (well, except if it uses extension methods declared on Object?). Any existing code would have chosen either dynamic, Object? or void in the existing algorithm, and dynamic has the same assignability and at least the same amount of member affordance (except extension), so it's the safe choice.

If we choose Object? then we avoid introducing an implicit dynamic, which carries the reward in itself. We may break existing code where the left-most superinterface happens to use dynamic as parameter type and the implementation performs dynamic invocations on the parameter.

If we choose void, we go all in on preventing member invocations, even Object members. There is no particularly good reason for that. If you implement an interface returning a non-void type then you have to return a value that can be used, even if you also implement one with a void return type. (In covariant position, it's an intersection type).

So, if parameter types are not considered special, and we use the same top-merge for all situations, rather than a contravariant one for parameters in contravariant position, then we should focus on the return type, and I'd suggest Object? over dynamic over void. That gives us Object? in case of conflict except if all types are dynamic or void, then it's dynamic, but that is also not surprising since dynamic occurs in the supertypes.
Then parameters do the same thing, which means that they become Object? if any super-interface method has Object? as parameter type, and void only if all of them have void.

An alternative is to use Object? always, no matter what conflict there is. The rule would be: No conflict, use the type as written. Any conflict between top types: Use Object? instead. (Or always use dynamic if going for compatibility instead of avoiding dynamic.) It's simpler, and the only difference is that a conflict between dynamic and void is resolved to Object? ... which is a kind of compromise between "allow everything" and "allow nothing" 😄.

[lrhn]

OK, if we maintain that contravariance is not worth it, and we do want to avoid dynamic where possible, then we will get some inconvenient void/Object? choices occasionally.

We currently only use NNBD_TOP_MERGE for merging member signatures. (Correct?)

Since void typed parameters are exceedingly rare, and the type of parameters rarely matter, we should make the choice which does "the right thing" in the (covariant) case of return types.

In that situation, the better choice is Object?.

If an interface implements both void foo(); and Object? foo(), then someone will be able to call foo and expect a value. The interface should promise to return that value.

The current definition says:

• NNBD_TOP_MERGE(Object?, void) = void
  • And the reverse

I'd prefer to change that to Object?.

If we plan to use NNBD_TOP_MERGE in other places too, say in LUB operations, then that preference would probably change. The LUB of two value expressions represents either-or of the possible values, where the unification of two member signatures represents a both constraint on the subclass. For a LUB result, I'd prefer void to Object? (which the "MORETOP" relation captures).

[eernstg]

We currently only use NNBD_TOP_MERGE for merging member signatures. (Correct?)

We use it for merging member signatures, and for computing the dynamic representation of implemented interfaces (cf. the wording 'for the purposes of runtime subtyping checks'). I would assume that the latter would apply to static assignability checks as well:

// opted_in.dart
class A<X> {}
class B1 implements A<int> {}
class B2 implements A<int?> {}

// opted_out.dart
// @dart = 2.7
import 'opted_in.dart';
class C implements B1, B2 { ... } // Or extends one of them.

//opted in
import 'opted_out.dart';

void main() {
  A<int> a = C(); // OK, `typeof(C()) <: A<int*> <: A<int>`.
}

[eernstg]

Decision: We use Object? as the merge of any two distinct top types.