Skip to content

language server: Option to auto-fill required param keyword for non-null arguments #48119

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

Open
micimize opened this issue Jan 10, 2022 · 2 comments
Labels
area-devexp For issues related to the analysis server, IDE support, linter, `dart fix`, and diagnostic messages. devexp-quick-fix Issues with analysis server (quick) fixes P2 A bug or feature request we're likely to work on type-enhancement A request for a change that isn't a bug

Comments

@micimize
Copy link
Contributor

Wanted to open an issue for discussing a potential flag to the language server / analysis server for automatically filling the required keyword when non-nullable arguments are specified.

As far as I know, this would be the first semantic-source-altering feature for the analysis server. I don't know if there has been an explicit decision to never implement something of the sort.

Discussion of language-level solutions:

The auto-fill feature should be discussed first, but as an aside, I think an elegant approach to such a feature would be to have it be bi-directional, so that an editor could toggle between "final source" and "truncated/tersified source." I doubt that would make sense if this is the only syntax rewrite that ever gets implemented though.

@bwilkerson
Copy link
Member

I think there are some interesting challenges to implementing something like this in the analysis server, and it isn't clear to me that doing so would be good for the user experience, but we do have another tool (dart fix) that might be a reasonable place for implementing such behavior.

We already have a fix to add the required keyword, but it isn't currently enabled for bulk application. The reason is that there are other equally valid fixes so we can't know which one the user is likely to want to have applied in a given situation. If we had a way for the user to specify which fix to apply for a given diagnostic, then we could apply that fix as part of bulk fixing.

@micimize
Copy link
Contributor Author

wherever it ends up, as long as it can be applied efficiently on file save it should be fine / satisfy this use-case, but I feel like that might be awkward to do with dart fix unless there are pre-existing plans to expand its API surface area / intended usage.

@srawlins srawlins added the P2 A bug or feature request we're likely to work on label Feb 4, 2022
@srawlins srawlins added the type-enhancement A request for a change that isn't a bug label Mar 14, 2024
@srawlins srawlins added the devexp-quick-fix Issues with analysis server (quick) fixes label Aug 16, 2024
@bwilkerson bwilkerson added area-devexp For issues related to the analysis server, IDE support, linter, `dart fix`, and diagnostic messages. and removed legacy-area-analyzer Use area-devexp instead. labels Feb 21, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-devexp For issues related to the analysis server, IDE support, linter, `dart fix`, and diagnostic messages. devexp-quick-fix Issues with analysis server (quick) fixes P2 A bug or feature request we're likely to work on type-enhancement A request for a change that isn't a bug
Projects
None yet
Development

No branches or pull requests

4 participants