(consider) supporting personalized code completion results

[pq]

EDIT: this topic began asking whether lambda arg completions should include types and provided the following motivation.

For example, double is certainly not what is wanted here:

The conversation has since moved to more general mechanisms for customizing completions so I've repurposed the issue to carry those ideas forward.

[bwilkerson]

Not including type annotations in closures is a style choice, not a language requirement.

It's interesting to think about whether it's better, in general, to tailor the suggestions for a certain set of style choices or whether it should support all valid uses of Dart. I don't have an answer to that question, but I do think that if we're going to make changes like this one that it needs to be based on a conscious choice to exclude support for valid code that doesn't conform to that style.

[pq]

You make a good point and I think my suggestion was maybe too big of a hammer to solve a UX issue I hit when experimenting w/ range selections for lambda completions. (Easier to explain in person.)

Regardless of whether this would help in that case, the general question stands around how opinionated we want completion to be and whether we want its behavior to be influenced by things like lint rule settings. I'd be curious what @InMatrix thinks about that.

[devoncarew]

We have discussed in the past doing things like putting settings in the analysis options file which could control style choices like this. I don't think we had a single case compelling enough to do it.

  settings:
    include-types-for-closure-completions: true

As Phil mentions above, for some settings, we could infer the user's desired value from the set of lints they have enabled.

[bwilkerson]

Settings might be a good solution for this, as long as it doesn't get too out of hand, but I'd advise that we only add settings when we really can't satisfy all users without them.

If we do add settings, we should put them in the analysis options file. Not enabling a lint isn't a very clear indication that someone doesn't want to follow that style. And we should add some tooling support to improve discoverability of the options.

[pq]

Not including type annotations in closures is a style choice, not a language requirement.

FWIW it is recommended style:

https://dart.dev/guides/language/effective-dart/design#avoid-annotating-inferred-parameter-types-on-function-expressions

(Which is just to say this might not be a bad place to be opinionated. 🤔)

[shinayser]

We have discussed in the past doing things like putting settings in the analysis options file which could control style choices like this. I don't think we had a single case compelling enough to do it.

  settings:
    include-types-for-closure-completions: true

As Phil mentions above, for some settings, we could infer the user's desired value from the set of lints they have enabled.

Nice to know this conversation is happening! As I said on #40202 (comment) , could be interesting if we could give more analizer options to the infered parameter name, with three posible values:

• Full parameter name (default behavior)
• Abbreviated (first letter?)
• it (as is Kotlin, and after Abbreviated function literals language#265 get implemented, it could become the default behavior 😁)