I've not been a fan of the 'omit dynamic' rule for this reason. It's hard to differentiate between something explicit or something forgotten.

Removed Type-Defect label.
Added Type-Enhancement, Analyzer-Hint, Triaged labels.

Added Area-Analyzer label.

Added this to the Later milestone.
Removed Priority-Unassigned label.
Added Priority-Medium label.

+1 to warnings when public types are not specified.
...and please also add a flag to warn when ANY non-inferable types are missing a type declaration.

Removed this from the Later milestone.
Added Oldschool-Milestone-Later label.

Removed Oldschool-Milestone-Later label.

I just saw a demo of typescript in VisualStudio where they have the option of treating missing type declarations as "no type" instead of "any" (dynamic), which highlights where you should add type annotations.

This is pretty much the flag/mode that is discussed here. Please reconsider the priority for this!

This comment was originally written by @mezoni

Even if this is useful this will be a great contradiction of the basic concept of the proposed Gilad Bracha.

If we recognize that it is useful we should turn out that all these years, the whole concept was false.

============
https://www.dartlang.org/articles/optional-types/

Optional Types in Dart
Written by Gilad Bracha
October 2011 (updated September 2012)

One of the Dart programming language’s most innovative features is the use of optional types.
============

But get warning (as proposed here) should means that a whole concepts are wrong.
Because this will prevent to use type annotation optionally (do not use them and do not get a warnings).

This comment was originally written by beatgammit...@gmail.com

But get warning (as proposed here) should means that a whole concepts are wrong.

I don't think that's true if it's off by default.

Having this tool is very useful when working on a library since it gives a TODO list for documentation.

I still think optional types is a very good thing, since it allows rapid iteration in the beginning and documentation when the code stabilizes. Libraries should nearly always be stable, so they should nearly always have complete type annotations.

This is covered by the linter: type_annotate_public_apis.