CFE is not inferring generic type for const default parameters

[vsmenon]

DDK asserts on the following. DDC does not. In the constructor of C, the CFE is instantiating B with Null (causing the error). The analyzer with T (which works).

class A<T> {
  const A();
}

class B<T> implements A<T> {
  const B();
}

class C<T> {
  final _a;

  const C([A<T> a = const B()]) : _a = a;
}

void main() {
  var c = new C<String>();
  print(c._a.runtimeType);
  assert(c._a is! A<Null>);
}

The result with DDK is:

B<Null>
Assertion failed: is not true Error

@a-siva is hitting this in package:collection.

@kmillikin

[vsmenon]

@stereotype441 @leafpetersen @lrhn - Paul says this is a bug in analyzer.

Here's the actual repro with collection:

import 'package:collection/equality.dart';

void main() {
  var eq = const ListEquality<String>().hash(["hello", "world"]);
}

It throws with CFE:

Type 'String' is not a subtype of type 'Null' in strong mode Error
    at Object.dart.throw (/Users/vsm/ddctest/node_modules/dart_sdk.js:4902:27)
    at Object.dart.castError (/Users/vsm/ddctest/node_modules/dart_sdk.js:4830:15)
    at Object.dart.as (/Users/vsm/ddctest/node_modules/dart_sdk.js:4801:15)
    at Function.check_Null [as _check] (/Users/vsm/ddctest/node_modules/dart_sdk.js:43361:15)
    at DefaultEquality.new.hash (/Users/vsm/ddctest/siva3.js:185:9)
    at ListEquality.new.hash (/Users/vsm/dart/sdk/third_party/pkg/collection/lib/src/equality.dart:173:15)
    at siva3.main (/Users/vsm/ddctest/org-dartlang-app:/siva3.dart:5:18)

[lrhn]

Paul is correct. You cannot write const B<T>() as the parameter default value since T is not a compile-time constant. We do not evaluate default values per invocation. We could change that and not require the expression to be constant at all, but we currently don't.
So, const B<T>() is invalid whether the T is explicit or inferred, so we don't infer T. The only valid type to infer is const B<Null>() - the one const expression that is assignable to B<T> for any T, so that will be the const expression post-inference.

(We actually do not consider parameter default values as an implicit const context where you can omit const because we are keeping the door open to making it non-const).

[stereotype441]

In the package:collection example, the way the analyzer bug manifests is that the constructor for ListEquality, which looks like this:

class ListEquality<E> implements Equality<List<E>> {
  const ListEquality([Equality<E> elementEquality = const DefaultEquality()]) ...;
}

gets inferred as:

class ListEquality<E> implements Equality<List<E>> {
  const ListEquality([Equality<E> elementEquality = const DefaultEquality<E>()]) ...;
}

That's not legal, since E is not const. The correct Dart 2.0 behavior (which the front end implements) is to infer a type parameter of Null:

class ListEquality<E> implements Equality<List<E>> {
  const ListEquality([Equality<E> elementEquality = const DefaultEquality<Null>()]) ...;
}

Unfortunately, that causes a (correct) strong mode runtime error, because ListEquality.hash calls DefaultEquality.hash, and DefaultEquality.hash has signature:

int hash(E e);

Since E is Null, soundness requires that we don't allow anything but null to be passed to hash, so the front end inserts a runtime type check. There's a similar problem with DefaultEquality.equals.

One possible solution would be to change the signature of DefaultEquality.equals and DefaultEquality.hash like so:

bool equals(Object e1, Object e2);
int hash(Object e);

[vsmenon]

The suggested solution (use Object in DefaultEquality) seems to do the trick.

[lrhn]

That seems like it would work - a class that implements Equality<Null> and accepts Object on any argument is really the equivalent of Equality<dynamic> in Dart 1. It's assignable to any Equality<T> and it's callable with any argument. It might be a little surprising that new DefaultEquality<int>().equals("a", "b") works (but then == was always defined to accept any object).

We could even make DefaultEquality always implement Equality<Null>, instead of having a type argument, but I guess that's a little too clever (and breaking).

It's annoying that we have to make this workaround to dodge the type system, but luckily it's fairly localized.

[nex3]

It does seem, intuitively, like inferring DefaultEquality<E> should work here, even if we don't allow fully non-const default arguments. E is bound by a const context—at the point at which the const constructor is invoked, E is known at compile-time.

[lrhn]

There are multiple issues that prevent this.

• Default values are compile-time constants, so the expression must always evaluate to the same value. That's a general rule for compile-time constant expressions.
• Default values are single values, they are not evaluated once per invocation (same thing, but at the conceptual level - we can't document a value in the DartDoc if it changes per invocation).
• And finally, a const constructors can also be invoked with new, so there isn't necessarily a const context at all.

All of these prevents the default value from both depending on E and being compile-time constant.

[leafpetersen]

All of these prevents the default value from both depending on E and being compile-time constant.

Sort of. There is a notion of a potentially const expression to handle this at the term level, right? So why not at the type level? Wouldn't that work here?