No way to verify that a list argument's entries are valid in a const assert

[Hixie]

abstract class MultiChildRenderObjectWidget extends RenderObjectWidget {
  const MultiChildRenderObjectWidget({ Key key, this.children: const <Widget>[] })
    : assert(children != null),
      assert(!children.any((Widget child) => child == null)), // <-- this line won't compile
      super(key: key);
  // ...
}

[lrhn]

Correct. Const expressions cannot iterate over lists or call methods. That is not new, it is a know restriction on compile-time constant expressions, and not something we expect to change.

That does restrict what you can do with compile-time constant asserts, but no more than it restricts what you can do with const expressions in general.

As a rule, you cannot deconstruct composite values (whether lists or other objects) at compile time, you can only build them.

[mathieujobin]

assert(children.all((Widget child) => child != null)) would be more readable IMO

[tvolkert]

Revisiting this. This one assert is too useful to remove, and the fact that it's keeping MultiChildRenderObjectWidget from being const constructible is keeping large swaths of app code from being const constructible (because Row and Column are both descendants of MultiChildRenderObjectWidget).

[dnfield]

When non-nullability comes in, will we have List<T> where T is non-nullable?

[eernstg]

Definitely yes.

[a14n]

Plugged question regarding assert in initializer list: I often wonder why they are part of the const evaluation? If they were executed only at the first initialization we could make almost every widget classes const (especially Row, Column, and Stack) without changes.

[cedvdb]

How is that assert valuable ? If the children is a List<Widget> the elements cannot be null (dynamic not included), can they ?

[dnfield]

It's still valuable as long as we have customers running in unsound null-safety mode, and we still have a substantial number of those.

[gustav3d]

There are other breaking changes happening all the time. So no, it is not, it's their problem that they refuse to fix their code but still expect things to function in any new version. So let them be stuck on version X like in all other cases of breaking changes.

…

On Fri, 19 Nov 2021 at 01:05, Dan Field ***@***.***> wrote: It's still valuable as long as we have customers running in unsound null-safety mode, and we still have a substantial number of those. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#29276 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABCY4M36BWDJ43NUN26T4LUMWIERANCNFSM4DGUUDBA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[cedvdb]

I did not know they could run on unsound null safety while at the same time receive updates from flutter.. That sounds like a significant maintenance annoyance. Hopefully there are plans to drop that

[mateusfccp]

When will unsound null-safe mode be deprecated?

We shouldn't restrain ourselves for so much time because some people refuses to progress...

[lrhn]

Don't restrain yourself. Write perfectly good null safe code, then allow that code to crash and burn if someone passes in a null argument to a non-nullable parameter. Don't bother writing if (arg as dynamic == null) throw NiceError("this thing shouldn't be null"). Just let the dice roll and see where the null crashes things.

They had it coming. They only had themselves to blame.

[dnfield]

The last I checked on what data we have for this, >20% of Flutter users are using unsound null-safety. As nice as it would be to just migrate, the user experience of getting nonsensical errors at some unexpected place in your program is pretty bad.

[larssn]

Isn't this one of those things that's purely theoretical? Do you have any data on how often people run into this assertion?

For us, still running unsound, we've never run into it.

It seems like a pretty niche thing, and for it to hold the codebase back for the majority of users is not something I agree with, even though we're not going to benefit from it atm.

So pull the trigger. 🙂

[dnfield]

Isn't this one of the things that's purely theoretical? Do you have any data on how often people run into this assertion?

For us, still running unsound, we've never run into it.

It seems like a pretty niche thing, and for it to hold the codebase back for the majority of users is not something I agree with, even though we're not going to benefit from it atm.

So pull the trigger. 🙂

We have data that a large number of users are still running code in unsound null-safe mode, where this assertion is helpful.

Dart 3 will be removing this problem before very long. We can just wait for that.