I think probably how this should be landed is by bumping the min sdk version in the pubspec to be a 2.9 release, and removing the // @Dart comments in the opted in files entirely. @jakemac53 @jonahwilliams does that sound right?

That sounds like an approach with less churn. Is 2.9 the null safety language version, or could that change?

2.9 will not be the final null safety language version. It is likely, but not guaranteed that 2.10 will be the final null safety language version.

okay, in that case we should definitely do it in the pubspec so there is only a single location, right?

I prefered to explicitly use // @dart = 2.9 during the incremental migration for simple searchability. Once all framework is migrated I will remove it. Note that the pubspec.yaml sdk version is already pointing to 2.9.

Does it look good to you?

Ok, works for me. Note that if/when the Dart version bumps to a 2.10 pre-release, there will a bit of a bump - you won't be able roll 2.10 in until you change all of these from // @Dart = 2.9 to // @Dart = 2.10.

could we set it to 2.10 now?

could we set it to 2.10 now?

You could try it, but I wouldn't really recommend it. You're more or less relying on undefined behavior in that case. It might just work, in which case it's probably fine, but it also might work in some places and not others, or suddenly stop working, or whatever.

If this is really just about tracking which things are migrated, maybe consider just using some other arbitrary string to tag them? // @Dart = migrated ?

Ok I'll remove it directly. I don't use it too much now.

Is there an issue on file that we could link from here?

link to issue added.

Why do we turn this one off?

This is needed to avoid warning on null assertion on non-nullable variable. For instance:

void m(String s) {
  assert(s != null);
}

This could change with #61042

If the variable itself is already non-nullable, why do we still need the assert? Wouldn't we want to clean that up and remove it?

Either way, It would probably be good to have a comment on this line explaining why we turn this off.

If the variable itself is already non-nullable, why do we still need the assert?

See dart-lang/language#1018:

At first glance, it might seem sensible to remove the assertion on the grounds that c can no longer be null, but that's only true in strong mode. Flutter will have a long tail of users running in weak mode until Dart 3.0, and assertions like these are necessary to help prevent them from passing nulls to Flutter APIs.

Thanks for the context and adding it as a comment.

This feels like a strange thing to add to flutter's public API. Looks like it is only used in one file. Can we just add it as a private thing there? Or, instead of using promote, can you just do the following in the code:

num n = 42;
n = n as int;
n.isEven;

I don't remind the issue but @Hixie suggested to add this function.

Finally I removed this function for now.

Why late?

IIRC this will make the field lazy initialized.

It won't do anything in this case (other than maybe make it slower to access). It allows you to (yourself) lazily initialize it but leave it as a non-nullable type.

Sorry if this wasn't clear, but my question was meant as: "Why are we declaring this field as late? It seems unnecessary here."

It was lazy before - I think there was a misunderstanding around what late means. If assigning immediately it has no meaning @stereotype441 should we have a lint for this?

To restore the lazy behavior that existed before this would have to be a nullable field type, and you would have to restore the old logic.

@jakemac53 that's not correct. late with an initializer means lazy.

Now I am confused. What is the difference between those two lines?

late final int foo = 1;
final int bar = 1;

Nothing, because you can't observe laziness with a value. But:

class A {
  late final int foo = (() {print("hello"); return 1;})();
  final int bar = (() {print("world"); return 1;})();
  A();
}
                            
                            
void main() {
  var a = A();
  print("says");
  a.foo;
}

outputs

world
says
hello

because a late variable with an initializer only evaluates its initializer on first use.

cc @munificent this is something we're going to have to explain carefully.

Thanks for the explanation!

What's currently stopping us to do this?

late is a little dangerous for public member. I'm not sure the TODO is still relevant. I'll check.

I am not sure I fully understand, lastWordStart seems to be private to this method?

comment removed. I added it to remind me that a lint could be done to use late.