Have a plan for replacements for strong-mode options that will be deprecated

[kevmoo]

This is a "discussion" issue for now...but we should figure this out.

Guessing we want to keep the implicit- flags.
Guessing we want to deprecate (And eventually remove) the strong-mode parent.

analyzer:
  strong-mode:
    implicit-casts: false
    implicit-dynamic: false

CC @kwalrath @dgrove

[bwilkerson]

The strong-mode flag/group does not make sense in Dart 2. We are not going to allow users to disable strong-mode semantics. So, yes, we will remove it.

We should allow users to request restrictions that are not required in Dart 2 if there is sufficient demand for the functionality. The mechanism we have defined for doing this is lints. So, for each of the options under discussion, if we decide to support them, we should create a lint rule that flags the style of code that some users might want to disallow, and we should remove the flags from the analysis options file.

As an aside, there are three options that are currently allowed under the strong-mode group: declaration-casts, implicit-casts, and implicit-dynamic. I'm not sure which of those actually make sense in the context of Dart 2. @leafpetersen @lrhn Could you address this question?

@kevmoo Can you determine, for each existing flag that makes sense, whether there is sufficient demand for us to create lint rules to cover those semantics? (I think you know more about how to ask our customers about this issue than I do.)

[lrhn]

As an aside, there are three options that are currently allowed under the strong-mode group: declaration-casts, implicit-casts, and implicit-dynamic.

I'm not absolutely sure I know what they mean, so let's see if I get it right:

• "implicit dynamic": Disallows programs where inference would infer dynamic in some (all?) position.
• "declaration casts": Disallows programs with implicit down-cast of a variable declaration initializer expression.
• "implicit casts": Disallows programs with implicit down-cast anywhere (except in declarations?)

In any case, these are all valid lints for Dart 2 - they disallow some programs, but they don't change the behavior of any accepted program.

As lints, it's important to limit the damage to your own code. It would be sad if someone enables such a lint, and then can't use a package that didn't use the lint. I guess this is no different from any other lint.

(And I think it would be more consistent if the new flags were named so that they default to false).

[bwilkerson]

Ok. I believe we have a plan. I'm going to rename this to reflect implementing the plan and move it to a later milestone.

[kevmoo]

Ok. I believe we have a plan. I'm going to rename this to reflect implementing the plan and move it to a later milestone.

What is the plan?

Can we split up the work? Ship new options soon and give the user deprecation warnings

...then remove support in the last milestone?

[leafpetersen]

This sounds reasonable to me.

[leafpetersen]

How does this affect the command line analyzer? I'm kind of confused about how lints interact with the general analyzer ecosystem - they tend to be off to the side, but these are much more integrated.

We also need support for this in the new front end, so there needs to be some common story there as well.

[bwilkerson]

How does this affect the command line analyzer?

The command-line analyzer runs any lints that are either (a) specified in the analysis options file or (b) specified on the command-line. Server also runs lints specified in the analysis options file, but doesn't have command-line support.

... these are much more integrated.

In what way?

We also need support for this in the new front end ...

We do? Why? (I'm not trying to challenge the statement, just understand the implications.)

[leafpetersen]

... these are much more integrated.

In what way?

Even with the existing no-implicit-dynamic, it seems difficult but perhaps not impossible to implement this separately from the code that does inference.

With proposed changes to no-implicit-dynamic (or a similar new flag, see #30397), I think it may be hard to do this: you need to know something about how dynamic was arrived at (e.g. via downwards inference, upwards inference, LUB, etc).

We also need support for this in the new front end ...

We do? Why? (I'm not trying to challenge the statement, just understand the implications.)

If this isn't implemented in the NFE, then you certainly need at least enough support to implement it in the analyzer behind the NFE. But more broadly, these should be usable via the DDC and other compiler interfaces as well, which I think won't be connected to the analyzer.