Linter: Deprecate avoid_as?

[a14n]

As of https://github.com/dart-lang/sdk/issues/34097#issuecomment-433409130

We've unified the implementation of implicit/explicit as checks in the VM to make them perform equally fast. We decided to retain the two different exceptions being thrown without extra penalty.

Not sure how dart2js handles explicit as checks. Is there an extra penalty ? Perhaps @sigmundch knows.

[pq]

Interesting. I totally missed this discussion. Thanks!

[sigmundch]

For dart2js it still is uneven: we haven't invested in optimizing away checks because many customers use --omit-implicit-checks (included also with -O3 and -O4). We are however starting some changes to our runtime type representation to prepare for it in the future.

At this time, the --omit-implicit-checks flag removes the implicit casts, but keeps around the explicit casts, so the former have no cost but the latter do. An alternative we've considered instead of optimizing away the checks is to omit all casts. For that purpose we have added a --omit-as-casts flag, but we haven't experimented too much with it. If we decide to include it as part of -O3 and we validate with our customers that it works as expected, then we would be in a position to say that explicit and implicit checks have the same cost in dart2js as well.

[lexaknyazev]

My casts look like:

// Iterator<num> iterator;
// In case when values are guarantied to be ints:
while (hasNext) {
  final int value = iterator.current;

Before Dart SDK 2.1.1, analyzer's implicit-casts didn't cover "declaration" casts that avoid_as description recommends:

... If you know the type is correct, use an assertion or assign to a more narrowly-typed variable ...

With the latest SDK version, I have to either enable implicit-casts or to use as (and disable the lint). The comment above about dart2js suggests that it's worth performance-wise to choose the former even if it makes code less type safe, right?

[nstrelow]

Can this lint rule now be deprecated or does it still apply in dart2js?

Using this rule for a Flutter app which runs also in web.

Might be completely unrelated, but
I have a weird issue with https://github.com/google/json_serializable.dart/issues/656, where as String breaks Flutter web release builds. toString() works

[bwilkerson]

@sigmundch @rakudrama

[sigmundch]

For dart2js there is still a benefit when using --omit-implicit-checks, but with null-safety implicit casts are no longer allowed unless the input has type dynamic. So I think deprecating the lint is a good choice at this time. Otherwise, it should at least be fixed to only trigger when the input is dynamic if the enclosing library has opted into null safety.

[mraleph]

I got a question about this lint on Twitter in context of Flutter - we should definitely either deprecate it or at least make it explicit _why_ it is there and which platforms it applies to. People are confused because this lint is enforced in Flutter and it sends a confusing message that implicit casting is somehow cheaper than as, which makes no sense on VM platform as it never unsoundly omits any checks.

Recommendation to use is instead of as is also somewhat confusing (I guess concern was about code size for exception throwing?).

/cc @Hixie

[Hixie]

Yeah this is obsolete, we should just remove it, at least as a default if it's still enabled anywhere.

[pq]

+1 for deprecating and I'll take that on.

(FWIW I don't see it enabled anywhere in flutter but it definitely _used to be_ so the confusion could be lingering or the user is on an old branch.)