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

In "Dart Programming Language Specification 6th edition draft Version 2.15-dev" page 35 #2097

Closed
horo99 opened this issue Feb 7, 2022 · 3 comments
Assignees
Labels
bug There is a mistake in the language specification or in an active document

Comments

@horo99
Copy link

horo99 commented Feb 7, 2022

image

before is the code in specification, below is the fact in my ide

image

My dart version shows as below,
Dart SDK version: 2.15.1 (stable) (Tue Dec 14 13:32:21 2021 +0100) on "macos_x64"

@horo99 horo99 added the bug There is a mistake in the language specification or in an active document label Feb 7, 2022
@horo99
Copy link
Author

horo99 commented Feb 7, 2022

I know the specification I'm learning is a dev version, and I don't know it is right to commit a bug with the dev version specification like this way.

@lrhn lrhn assigned lrhn and eernstg and unassigned lrhn Feb 7, 2022
@eernstg
Copy link
Member

eernstg commented Feb 7, 2022

@horo99 wrote:

specification I'm learning is a dev version

Reporting a specification bug in this repo is fine!

However, the current version of the specification does not include null safety, and the example is correct for pre-null-safety Dart.

Parts of a new version of the language specification that introduces null safety are under review. This new version includes a fix for this example (and for a few thousand other things ;-). The corrected program looks like this:

class A {
  noSuchMethod(covariant Never n) => n;
}

void main() {
  dynamic d = A();
  d.foo(42); // Dynamic type error when invoking noSuchMethod.
}

It may seem silly to have a formal parameter whose type is Never (because it's never possible to successfully pass any actual argument to that parameter), but the point is still the same: We get a dynamic error because the given argument does not satisfy the typing requirement associated with the formal parameter, we don't get an infinite loop where each invocation of noSuchMethod directly causes another invocation of noSuchMethod.

Parts of the null-safety update is under review in #2023 and #2052, but the null-safety update consists of several additional parts, so it will take a while before everything has been landed (and this particular change is neither part of 2023 nor part of 2052).

Until then, please take the null safety specification into account as well as the language specification, in order to see how the language with null safety is defined.

@eernstg eernstg closed this as completed Feb 7, 2022
@horo99
Copy link
Author

horo99 commented Feb 8, 2022

Thanks!
Your reply is very helpful for me.
I forgot the type 'Never' before. I will firstly go to make a more totally understanding about null-safety via null safety specification before learning the specification. Thank you again!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug There is a mistake in the language specification or in an active document
Projects
None yet
Development

No branches or pull requests

3 participants