A potentially spurious expected upper bound in an extension types test

[chloestefantsova]

It seems that in the following lines Object should be the expected upper bound between ET3("String") and ET4(3), not Object?, because both types are non-nullable.

co19/LanguageFeatures/Extension-types/upper_bound_A01_t05.dart

Lines 35 to 36 in 9d347fd

	var v3 = 2 > 1 ? ET3("String") : ET4(3);
	v3.expectStaticType<Exactly<Object?>>();

[chloestefantsova]

/cc @eernstg

[eernstg]

Right, ET3<String> and ET4<int> both have Object as a supertype because their representation type is non-nullable. It is intended that this should cause Object to be encountered in their superinterface graphs, and the standard upper bound could then not be Object?, it would be at least Object.

However, I think the specification fails to make this work in cases like this one. We have the following rule:

If DV does not include an <interfaces> clause then DV has Object? or Object as a direct superinterface, according to the subtype relation which was specified earlier.

This is sufficient to give rise to the desired superinterface graph for an extension type with no <interfaces> (that is, with no implements ... clause), but it does not suffice for the case we have here. We should actually have this rule:

DV has Object? or Object as a direct superinterface, according to the subtype relation which was specified earlier.

It may well be a seemingly redundant edge in the superinterface graph because there is some other way to Object or Object?, but in cases like in this issue we do not have that other way to Object.

So please consider the specification to be adjusted as mentioned above, and keep an eye on dart-lang/language#3402.

[lrhn]

The intention is that an extension type is non-nullable if its representation type is, because we make it have Object as supertype then, and definitely not non-nullable if its representation type isn't, so it's always precisely the same non-nullability as the representation type. (An extension type is never nullable.)

I agree that the current text fails to capture that.

Whether an extension type is non-nullable is a property of the type, not the declaration. It doesn't necessarily make sense to ask whether a generic extension type declaration is non-nullable or not.

Sometimes it's easy, and we can see that the declared representation type is non-nullable, which means that it will be non-nullable no matter how the type variables are instantiated.

Other times the representation type is trivially always nullable.

But in cases like:

extension type E<T>(T _) {
  void foo() {
    this ?? print("really?");  // Valid code, shouldn't have warnings.
  }
}

we can't say whether E, the declaration, is non-nullable and has Object as superinterface, because it's not a question that can answer at the level of the declaration. It's only known for actual types.

[sgrekhov]

Fixed by #2314. But I'm not closing this issue. First, please note that the tests is still failing in both analyzer and CFE

co19/LanguageFeatures/Extension-types/upper_bound_A01_t05.dart

Lines 32 to 33 in 9d347fd

	var v2 = 2 > 1 ? ET1<String>("String") : ET2<String?>("String");
	v2.expectStaticType<Exactly<Object?>>();

Tools are expecting Object on line 33. Is this a tests issue?

I'm also going to add more tests regarding nullability as part of this issue. In particular we have no test that there should be no warning in case of

extension type E<T>(T _) {
  void foo() {
    this ?? print("really?");  // Valid code, shouldn't have warnings. But we have!
  }
}

[eernstg]

Tools are expecting Object on line 33. Is this a tests issue?

ET1<String> has Object as a direct superinterface and in turn Object?. ET2<String?> has Object? as a direct superinterface. The standard upper bound of the two should be Object?. I can't see any other choice, so this would be a tools issue.

I'm also going to add more tests

Sounds good! The fact that this can be null should be a property which is shared with extension declarations (and with the class Null ;-), but it would in any case be possible for the ?? expression to evaluate the right hand expression. So we should not get a warning.

[chloestefantsova]

The CFE compiles line 33 without emitting an error message. That may be due to the landing of dart-lang/sdk@c658b46 earlier today.

[sgrekhov]

The CFE compiles line 33 without emitting an error message. That may be due to the landing of dart-lang/sdk@c658b46 earlier today.

Yes, confirming. No CFE issue on the top SDK. Analyzer issue only

[sgrekhov]

dart-lang/sdk#53781