Never use as.

[pq]

As per #57238.

[pq]

First cut at some descriptive text.

From the flutter style guide:

AVOID using as.

If you know the type is correct, use an assertion or assign to a more narrowly-typed variable (this avoids the type check in release mode; as is not compiled out in release mode). If you don't know whether the type is correct, check using is (this avoids the exception that as raises).

BAD:

try {
   (pm as Person).firstName = 'Seth';
} on CastError { }

GOOD:

Person person = pm;
person.firstName = 'Seth';

[Hixie]

The "GOOD" for that "BAD" would be more like:

Person person = pm;
person.firstName = 'Seth';

The "BAD" for that "GOOD" would be more like:

try {
   (pm as Person).firstName = 'Seth';
} on CastError { }

[pq]

Updated. Thanks!

[zoechi]

This seems to conflict with strong mode
I changed

options.include = JSON.decode(include) as Map<String, List<String>>; // warning: avoid as

to

Map<String, List<String>> json = JSON.decode(include); // error: will need runtime check 
options.include = json;

just to get the warning that it will need a runtime check.
@Hixie don't you use strong-mode? It seems to comply with your approach to get proper warnings for all type violations?
Or did I miss some way to work around one of these warnings?

[Hixie]

We filter out that strong mode warning.

We don't actually use strong mode itself (i.e. DDC and its dart-to-js conversion). We do turn on the strong mode warnings in the analyzer, but only because they happen to catch some things we want to catch. They also catch things we don't want, and we have a script that filters those out:

https://github.com/flutter/flutter/blob/master/packages/flutter_tools/lib/src/commands/analyze.dart

Ideally we'd have all the warnings we could want with strong mode off. It's not our goal to influence the DDC work, which has a very different purpose than what we're doing.

[zoechi]

@Hixie thanks a lot for explaining your take on strong mode.

[stt106]

if the advice is "never use as", then maybe "as" should be removed from the language?

[zoechi]

@stt106 that was for Dart 1. This is quite a different story in Dart 2.

[stt106]

@zoechi Then why in https://raw.githubusercontent.com/flutter/flutter/master/analysis_options.yaml it still says "avoid using as" ?

[zoechi]

@stt106 #34582 not exactly sure how to interpret the last comment though.

[Hixie]

We (Flutter) haven't removed that lint yet because we want to remove the lint at the same time as we update all the code to use as instead of implicit downcasts. It'd be even worse for the codebase to be inconsistent.

[truongsinh]

in the example
GOOD:

if (pm is Person)
  pm.firstName = 'Seth';

BAD:

try {
   (pm as Person).firstName = 'Seth';
} on CastError { }

I would rather prefer
BEST:

if (!(pm is Person)) {
  // throw or early return
}
pm.firstName = 'Seth';

Should I create a new issue asking for this enhancement, as currently linter is not able to understand this?

[Hixie]

Try

if (pm is! Person)
  throw Exception('...');
pm.firstName = 'Seth';

...but note that that is a different semantic than the GOOD vs BAD case in the documentation. The point of the documentation's example is that a non-matching (and non-null) value will not result in an exception, it'll just be ignored. (In the case of the value being null, it'll throw in the GOOD case and not in the BAD case.)

In general, all three of these techniques aren't very good since they introduce knowledge of the class hierarchy outside of the interface defined by the class hierarchy, which breaks polymorphism.

[truongsinh]

thanks, I didn't know about is!, however, I don't think it works as expected:

void main() {
  dynamic a;
  List<dynamic> b;
  if (a is! List) {
    b = a; // expected, invalid_assignment
  } else {
    b = a; // UNEXPECTED; observed: invalid_assignment, expected no error
  }
  if (a is List) {
    b = a; // good, no error
  } else {
    b = a; // expected, invalid_assignment
  }
}

Btw, I think what i'm trying to achieve is similar to https://docs.swift.org/swift-book/ReferenceManual/Statements.html#grammar_guard-statement , which might be out of this issue's scope, or even linter's scope, but more into the language spec itself.