-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Have a plan for replacements for strong-mode options that will be deprecated #32661
Comments
The 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 @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.) |
I'm not absolutely sure I know what they mean, so let's see if I get it right:
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 |
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? |
This sounds reasonable to me. |
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. |
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.
In what way?
We do? Why? (I'm not trying to challenge the statement, just understand the implications.) |
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
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. |
Not sure if this #32235 should be de-duped into this issue? |
I'd forgotten about that discussion. Thanks for reminding me.
I agree that they won't be connected to the analyzer. I have no opinion (at this point) whether it makes sense for them to be usable by the compilers. But assuming that it does make sense, what's the right way for users to think of these options? Do they change the semantics of the compiled code, or just the set of errors that are reported? Are they "language" options (choosing a variant of the language)? Do we have a complete (or even partial) list of the options that fall into this category? |
I can live without the implicit-* options especially since currently they apply to all dependent code and not just the current project code. I would prefer moving these to lint rules, if possible, that only apply to the current codebase. |
@leafpetersen What is the path forward here? This issue was presumably assigned to me because it originally looked like an analyzer issue. But if the compilers need to know about it (still not sure why; I'd love to understand, though) then it's no longer an analyzer issue. I'll mark it as a language issue and assign it to you for now, but please update it as you see fit. (I'm also moving the milestone back, given that the original request was to have an answer by the end of this milestone.) |
@leafpetersen what are your thoughts? |
@leafpetersen can you give an update? We're getting close on Beta4. |
We need to keep supporting these in the analyzer. For the CFE, we can worry about adding support for them post Dart 2 if needed. |
Removed from the Dart2 set of milestones. |
This is on my plate for this Q and next. |
Good news! We also have not deprecated the strong-mode options yet; nothing is reported when you use them. This is #47902. I'm closing this as we have come up with a plan and mostly executed it. |
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.CC @kwalrath @dgrove
The text was updated successfully, but these errors were encountered: