Should the migration to NNBD include eliminating implicit downcasts?

[leafpetersen]

Dart 2.0 assignability allows an assignment from something of type A to something of type B if A is a subtype of B or if B is a subtype of A. With non-nullable types, the implication would be that assignment of a nullable variable to a non-nullable variable would be silently accepted. This seems very contrary to the spirit of the NNBD change, and is inconsistent with what we expect from other languages.

One possible solution is to special case non-nullability with respect to assignability. For example, add a side condition that B must be nullable if A is.

An alternative is to take this opportunity to remove implicit downcasts from the language entirely as part of the NNBD opt in. Implicit downcasts seem to be a common source of confusion since they push a surprising amount of type checking to runtime. See background issues below for more discussion.

Topic specific discussion issues:

• Implicit cast operator syntax
• Casts during iteration

Background issues:

dart-lang/sdk#33749
dart-lang/sdk#31410
dart-lang/sdk#30402
dart-lang/sdk#32661
dart-lang/sdk#25368
dart-lang/sdk#29718
dart-lang/sdk#30385
dart-lang/sdk#29547
dart-lang/sdk#29548

[munificent]

YES PLEASE.

[matanlurey]

I am already planning the Piñata to ship to SEA upon this change.

[leafpetersen]

A key question is, how intrusive would this be to existing code bases. That is, would eliminating implicit casts add large amounts of syntactic noise to existing code bases. Here are a few examples of packages that have done this migration that I've found:

• analyzer cli
• analyzer server and plugin
• watcher (part of a larger set of changes)
• test (part of a larger set of changes, but mostly implicit cast related)
• file (lots of unrelated cleanup in that commit)
• markdown (some unrelated lints enabled in the same commit)
• mime (lots of unrelated changes)
• logging (lots of unrelated changes)
• process (some unrelated changes)

cc @mit-mit @munificent @lrhn

[munificent]

This isn't a super clean commit because it also includes a bunch of --no-implicit-dynamic fixes, but here is the commit where I fixed most implicit casts in my game. This file in particular shows casts I needed to handle processing some JSON. Overall, there weren't too many changes for casts and some bugs were discovered.

Here is the change in the SDK where I enabled --no-implicit-casts for test.dart. It also includes a bunch of --no-implicit-dynamic changes too. It's sort of a worst case example because, at the time, test.dart heavily used a giant map as its core data structure. This change was in fact intended to find the places where that map was used so I could replace it with an actual typed object.

[leafpetersen]

I filed an issue for discussing implicit casts during iteration here: #264 .

[eernstg]

Note that it could damage readability if we give up the distinction between arbitrary casts and downcasts:

// Assume that we have some unrelated classes `A` and `B`,
// and a class that implements both, `C`.
class A {}
class B {}
class C implements A, B {}

Here's some code as we could write it today (when accepting implicit casts):

main() {
  A a = C();
  B b = a as B; // Cast required, this is an "arbitrary" cast.
  C c = a; // Downcast, permitted.
}

If we just require all casts to be explicit then we'd have the following, which drops the hint that some casts are more risky than others:

main() {
  // All casts must be explicit.
  A a = C();
  B b = a as B;
  C c = a as C;
}

The point is that we could have explicit casts, and still avoid some of the verbosity, and still maintain the distinction between "less surprising" and "more surprising" casts (using !! for 'cast to context type if assignable, otherwise error'):

main() {
  // All casts must be explicit, but downcasts can be `!!`.
  A a = C();
  B b = a as B;
  C c = a!!;
}

[leafpetersen]

This is accepted.