Calling Object members on type literals as receivers

[chloestefantsova]

Consider the following line from a test.

co19/LanguageFeatures/Constructor-tear-offs/summary_A03_t01.dart

Line 90 in ed5f316

Expect.equals(Func.toString(), f1TypeName);

In it Func is a type literal referring to the declaration as follows:

co19/LanguageFeatures/Constructor-tear-offs/summary_A03_t01.dart

Line 76 in ed5f316

typedef int Func(int i);

According to a comment in a recent discussion (see dart-lang/sdk#52961 (comment)), that should be a compile time error, and I'm working on a CL that treats it that way (see https://dart-review.googlesource.com/c/sdk/+/315101?tab=checks).

Should the test in question expect a compile-time error in line 90? Alternatively, calls similar to T.toString() where T is a type literal can be rewritten as callToString(T), where callToString is defined as follows:

String callToString(Object? receiver) => receiver.toString();

Here's a list of more of the similar invocations of Object members on type literals as receivers.

• LanguageFeatures/Constructor-tear-offs/summary_A03_t01.dart, lines 90, 98, 105
• LanguageFeatures/Constructor-tear-offs/summary_A03_t02.dart, lines 95, 103, 110, 122
• LanguageFeatures/Constructor-tear-offs/summary_A03_t03.dart, lines 95, 103, 110
• LanguageFeatures/Patterns/patterns_lib.dart, line 43

[chloestefantsova]

/cc @eernstg

[eernstg]

Surely, we should consider how the test could perform the intended testing without Type.toString (unless it is actually testing toString of reified types, which it probably shouldn't ;-).

Next, it should indeed be a compile-time error to try to call a static function named toString on the type Func, and that is the only possible analysis of Func.toString().

As mentioned here it is possible to call the instance member toString on an instance of Type using (Func).toString().

Should the test in question expect a compile-time error in line 90?

That is one way to handle the expected treatment of Func.toString(), but it probably makes more sense to use callToString or (Func).toString() in order to avoid the issue entirely.

On the other hand, it would make sense to take the opportunity to test that the compile-time error is reported for Func.toString() and such. This could be in a new test, if it isn't tested already.

[eernstg]

Interesting: The test says 'Checks an example from the specification' where Type.toString() is used, cf. https://github.com/dart-lang/language/blob/4bee74430552de8208b665196cbc81f0054fd457/accepted/2.15/constructor-tearoffs/feature-specification.md?plain=1#L647.

[sgrekhov]

@chloestefantsova if you don't mind I'll update the tests after landing of your PR

[chloestefantsova]

@chloestefantsova if you don't mind I'll update the tests after landing of your PR

Sounds good. I'll approve the failures in my CL and will leave a message here when the CL has landed.

[sgrekhov]

@chloestefantsova https://dart-review.googlesource.com/c/sdk/+/315101?tab=checks is still not landed. May it was replaced by some other changelist?

[chloestefantsova]

@sgrekhov It turned out, this issue requires a breaking change process in order to be resolved. It has been shelved for some time. I hope it can be resolved relatively soon and will update on the progress here.