Non-nullable type used in examples

[jmewes]

Observed

The Dart Language Specification contains the following statement in the section "Classes > Instance Methods > The Method noSuchMethod":

Note that it must be a method that accepts one positional argument, in order to correctly override noSuchMethod in Object. For instance, it can have signature noSuchMethod(Invocation i) or noSuchMethod(Object i, [String s]),

However, if a method has the signature noSuchMethod(Object i, [String s]), it yields a compiler error:

Expected

Probably the example is outdated and should use a nullable type for the second parameter.

References

• https://github.com/dart-lang/language/blame/180b5ba19dc289e78a1341255e17086cd0f90f48/specification/dartLangSpec.tex#L2954

[srawlins]

Good catch! I think this spec is for the pre-null safe language though. That text is legal in pre-null safe code.

[jmewes]

The "6th edition draft" is for version 2.15-dev which I thought uses null safe by default.

[eernstg]

Thanks! Cf. #2343.

The CHANGELOG comments near the beginning of the language specification LaTeX source are associated with the language version which was the current language version when the change was performed, and that's actually misleading. It's been done like that forever, but we should consider how to choose "section" headers for these change log comments in a way that is more meaningful.

In any case, the plan is that the upcoming stable version of the language specification will specify the language version 2.13. That is, it will include null safety and non-function type aliases. Several PRs are available for that (e.g., #2023, #2052), but it takes time to get them landed. More recent language updates (e.g., super-parameters and enhanced enums) will be integrated into the language specification when the null safety spec has landed.

[jmewes]

Also see the first example code snippet in "10.7.1 Generative Constructors" of the Dart Programming Language Specification 6th edition draft:

[eernstg]

Also see

Thanks! This is already handled in the upcoming revision of the language specification where null safety is added, along with many, many other changes.

[jmewes]

In regards of the NNBD feature, you might also want to re-consider the following statement in section "18.11 Try":

An on-catch clause of the form catch (p1, p2) s is equivalent to an on-catch clause on dynamic catch (p1, p2) s.

void main() {
  try {
    throw 'Foo';
  // ignore: nullable_type_in_catch_clause
  } on dynamic catch (e, t) {
    print(e.runtimeType);
  }
}

As far as I can see they are not equivalent anymore with:

$ dart --version
Dart SDK version: 2.17.1 (stable) (Tue May 17 17:58:21 2022 +0000) on "linux_x64"

[jmewes]

Here is another snippet from section "15.2 Super-Bounded Types" which needs an update. Maybe it can be checked whether it has been updated when the ticket is closed:

Current:

class A<X extends num> {
  X x;
}
A<Object> a;

Updated:

class A<X extends num> {
  X x;

  A(this.x);
}
A<Object> a;

[eernstg]

they are not equivalent anymore

True; the version of the language specification that includes null safety has the following:

An on-catch clause of the form `catch (p1 , p2 ) B`
is equivalent to the on-catch clause `on Object catch (p1 , p2 ) B`.

So that update has already been made. I've uploaded the complete null-safety PR as #2605, so please take a look at that one if you wish to check whether any particular rule involving null safety has been updated.

Please note that #2605 will not be landed as such. It is used to extract smaller PRs (e.g. #2052). Whenever one of those smaller PRs is landed, the diff between the current version of the language specification and the one in #2605 will be reduced a bit. When #2605 is empty, everything has been transferred.

15.2 Super-Bounded Types

Good catch! The example needs to initialize x, and the super-bounded type must have a top type (Object -> Object? will do). Those changes are now included in #2605, thanks!

I'll close this issue now, because the normal procedure is to use one issue for one fault or action, and #2605 does already contain the changes needed according to this issue.

@jmewes, thanks a lot for the input! It would be great if you create a new issue if you notice another missing update or other faults!

[jmewes]

@eernstg ,

I am glad that those comments are useful and get addressed. I was not sure about that and not sure if I understood it correctly.

For me it is a nice exercise to read the specification. So, I'll create an issue if I find again something that doesn't fit and will try to get it right.