Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Calling Object members on type literals as receivers #2143

Open
chloestefantsova opened this issue Jul 20, 2023 · 7 comments
Open

Calling Object members on type literals as receivers #2143

chloestefantsova opened this issue Jul 20, 2023 · 7 comments
Assignees
Labels
status-blocked Blocked from making progress by another (referenced) issue type-enhancement A request for a change that isn't a bug

Comments

@chloestefantsova
Copy link
Contributor

Consider the following line from a test.

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

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

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
Copy link
Contributor Author

/cc @eernstg

@eernstg
Copy link
Member

eernstg commented Jul 20, 2023

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
Copy link
Member

eernstg commented Jul 20, 2023

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 sgrekhov self-assigned this Jul 20, 2023
@sgrekhov sgrekhov added the type-enhancement A request for a change that isn't a bug label Jul 20, 2023
@sgrekhov
Copy link
Contributor

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

@chloestefantsova
Copy link
Contributor Author

@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
Copy link
Contributor

sgrekhov commented Oct 3, 2023

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

@chloestefantsova
Copy link
Contributor Author

@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.

@sgrekhov sgrekhov added the status-blocked Blocked from making progress by another (referenced) issue label Feb 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status-blocked Blocked from making progress by another (referenced) issue type-enhancement A request for a change that isn't a bug
Projects
None yet
Development

No branches or pull requests

3 participants