Skip to content

Re-evaluation of assertions removal for const widgets #108248

Closed
#119195
Closed
Re-evaluation of assertions removal for const widgets#108248
#119195
Assignees
goderbauer
Labels
P3Issues that are less important to the Flutter projectc: proposalA detailed proposal for a change to Flutterframeworkflutter/packages/flutter repository. See also f: labels.r: fixedIssue is closed as already fixed in a newer version

Description

@albertodev01
albertodev01
opened on Jul 24, 2022

Use case

Right now, for backwards compatibility with non-nullsafe code, there still are some assertions that make some code impossible to be marked as const. For example:

Row(
  children: const [
    Text('Hello'),
    Text('World'),
  ]
),

This is valid but only the children list is constant, not the whole widget. In other words, we can't do this:

const Row(
  children: [
    Text('Hello'),
    Text('World'),
  ]
),

There already was an issue (#88359) to address this but it was closed due to this reason:

Is the reasoning here that we can remove the check because in an NNBD world List children can never contain null? We've left these kind of null checks in the code base for now because not all apps have migrated to NNBD yet and they still need these asserts for proper error reporting.

That was a valid point but almost one year has passed since then and I think the team could re-evaluate investigating if it's worth removing those assertions. They would make Row, Column, Stack and much more const-able.

A Container for example could also be const if some assertions were removed on its constructors.

Proposal

Remove the assert statement here for MultiChildRenderObjectWidget, which would make lots of widgets const.

Activity

  1. iapicca commented on Jul 25, 2022

    @iapicca
    iapicca
    on Jul 25, 2022

    the ubiquitous presence of like unnecessary assertion like : assert(children != null); (e.g.) really baffles me.

    I understand the backwards compatibility with non-nullsafe code,
    but sound null safety was introduced long time ago (March 3, 2021),
    I'm not sure if there is any point in allowing compatibility with legacy code

    It's clearly a technical debt and it does, albeit in limited fashion,
    have consequences in terms of performance
    @albertodev01 just provided an example of it

  2. danagbemava-nc
    added
    in triagePresently being triaged by the triage team
    frameworkflutter/packages/flutter repository. See also f: labels.
    c: proposalA detailed proposal for a change to Flutter
    and removed
    in triagePresently being triaged by the triage team
    on Jul 25, 2022

  3. albertodev01 commented on Jul 26, 2022

    @albertodev01
    albertodev01
    on Jul 26, 2022
    ContributorAuthor

    The Dart team is also planning to remove support to non-null-safe code:

  4. goderbauer commented on Jul 26, 2022

    @goderbauer
    goderbauer
    on Jul 26, 2022
    Member

    We plan to remove these asserts from the framework when dart discontinues non-null safety.

  5. goderbauer
    added
    P3Issues that are less important to the Flutter project
    on Jul 26, 2022

  6. albertodev01 commented on Sep 1, 2022

    @albertodev01
    albertodev01
    on Sep 1, 2022
    ContributorAuthor

    There is an interesting update: dart-lang/sdk#49530

    Looks like we should be able to remove those assertions somewhere around mid-2023 when Dart 3 will be out

  7. albertodev01 commented on Jan 19, 2023

    @albertodev01
    albertodev01
    on Jan 19, 2023
    ContributorAuthor

    Update: with the upcoming Dart 3 version, it may be a good time now to make this change.

    It seems that this issue might be addressed here: #118837

  8. gustav3d commented on Jan 20, 2023

    @gustav3d
    gustav3d
    on Jan 20, 2023

    Dear god, finally :)

  9. goderbauer commented on Jan 20, 2023

    @goderbauer
    goderbauer
    on Jan 20, 2023
    Member

    It seems that this issue might be addressed here: #118837

    Yeah, I am working on this as part of that issue.

  10. albertodev01 commented on Jan 23, 2023

    @albertodev01
    albertodev01
    on Jan 23, 2023
    ContributorAuthor

    We can close this as it's finally done 🎉

  11. albertodev01
    closed this as completedon Jan 23, 2023

  12. goderbauer commented on Jan 23, 2023

    @goderbauer
    goderbauer
    on Jan 23, 2023
    Member

    This is not quite done yet, but it is in progress. I am going to leave this open until its truly done.

  13. goderbauer
    reopened this on Jan 23, 2023
  14. goderbauer
    self-assigned this
    on Jan 23, 2023
  15. goderbauer
    closed this as completedin #119195on Jan 31, 2023
  16. danagbemava-nc
    added
    r: fixedIssue is closed as already fixed in a newer version
    on Feb 1, 2023

  17. github-actions commented on Mar 3, 2023

    @github-actions
    github-actionsbot
    on Mar 3, 2023

    This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.

  18. github-actions
    locked as resolved and limited conversation to collaborators on Mar 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

P3Issues that are less important to the Flutter projectc: proposalA detailed proposal for a change to Flutterframeworkflutter/packages/flutter repository. See also f: labels.r: fixedIssue is closed as already fixed in a newer version

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions