Convert into expression/block body priority

[FMorschel]

I'd say it is much more common for a user to prefer changing the shape of a function than to change the expected return type. I have no numbers to prove, so it is merely a guess.

So I'm proposing we review the priorities for:

• Convert to expression function
• Convert to expression body
• Convert to block body
• Convert to async function body
• Remove 'async' modifier

So they stay relatively in the order of the list above. Never the async related ones before the shape ones.

WDYT @bwilkerson?

[bwilkerson]

Your instincts are good, but don't quite match the data we have.

I can't find a fix titled "Convert to expression function", so I'm guessing that you meant "Convert to expression body".

I also can't find a fix titled "Convert to async function body" (though there is an assist with that title). I'm guessing that "Add 'async' modifier" is the fix you're thinking of, although the fix and the assist might be very different operations, both because they have different titles and because they're implemented by different correction producers (if they are the same we should deduplicate and make the titles match).

If I have the right fixes, then according to our data, the correct order for the fixes is:

Add 'async' modifier (dart.fix.add.async)
Convert to expression body (dart.fix.convert.toExpressionBody)
Convert to block body (dart.fix.convert.bodyToBlock)
Remove 'async' modifier (dart.fix.remove.async)

All four of these fixes have a corresponding assist (except maybe the one mentioned above). Interestingly enough, the correct order for the assists is slightly different:

Convert to expression body (dart.assist.convert.bodyToExpression)
Convert to async function body (dart.assist.convert.bodyToAsync)
Convert to block body (dart.assist.convert.bodyToBlock)
Remove 'async' modifier (dart.assist.remove.async)

[FMorschel]

I can't find a fix titled "Convert to expression function", so I'm guessing that you meant "Convert to expression body".

I think I got confused with so many names, sorry. Yes, I couldn't find it either now that I'm looking again.

I also can't find a fix titled "Convert to async function body" (though there is an assist with that title). I'm guessing that "Add 'async' modifier" is the fix you're thinking of, although the fix and the assist might be very different operations, both because they have different titles and because they're implemented by different correction producers (if they are the same we should deduplicate and make the titles match).

I'd have to check if they do work the same. I can open an issue for me to review them. Thanks! Edit: I've opened #61587.

---

But yes, I was talking about assists, and not fixes necessarily, I should've been clearer. Now, considering:

1. Convert to expression body (dart.assist.convert.bodyToExpression)
2. Convert to async function body (dart.assist.convert.bodyToAsync)
3. Convert to block body (dart.assist.convert.bodyToBlock)
4. Remove 'async' modifier (dart.assist.remove.async)

I'd still argue that even though our data suggests people do use more of dart.assist.convert.bodyToAsync, it doesn't necessarily mean they use that one more than dart.assist.convert.bodyToBlock, because both bodies can be converted to async. And point number two would be that we should try as much as we can to maintain consistency between all possible combinations of them, so keeping async ones with a lower priority in general might be the best solution.

---

If we were to discuss fixes, I'm not sure if there is any diagnostic that might introduce two of the above together, so I think we are safe to leave them as is.

[bwilkerson]

You're right that we don't have any data indicating the percentage of time users use dart.assist.convert.bodyToAsync on a block vs. an expression function body. But I can tell you that there is a huge difference in the number of uses of dart.assist.convert.bodyToAsync and dart.assist.convert.bodyToBlock. Enough of a difference that I don't think the question of percentages matters.

... we should try as much as we can to maintain consistency between all possible combinations of them ...

I'm not sure that's true. What's your thinking here in terms of why grouping like items would improve the UX more than having the more frequently used assists closer to the top of the list?

I ask because the UX / HCI research suggests to me that for a small list, especially when the contents of the list isn't stable, such as the code action menu, frequency of use is often the best choice.

[FMorschel]

I'm thinking of "muscle memory" (see #53819 (comment) for another user talking about this). I myself always have to read multiple times when I see each of the combinations above, because some of the time the async ones show up at the top and some of the time at the bottom.

If you disagree, it's fine, I have no real problem with this. It just feels like consistency would make me faster at choosing the option I want, and it would make my workflow easier.

[bwilkerson]

Consistency absolutely has value. But that just requires that items be sorted in the same way from one time to the next. It has nothing to do with how they're sorted (by category or by frequency of use). Maybe I misunderstood, but I thought you were advocating for using a category-based sort, and that's what I was questioning. (Category based sorting is particularly useful for long menus, so I'm also not saying that it's never the right answer.)

[FMorschel]

I am advocating for category, but I'd be satisfied with usage too.

My point would be that, for example, since you pointed it out yourself, the difference is huge between turn into async and to block body, right? That is because most of the times, users are working with block bodies. But I've opened this because when I recently tried using the Convert to block body one in a bunch of methods, I was so accustomed with the ordering of the Convert to expression body being first, that I accidentally made the wrong change (adding async) a bunch of times.

[bwilkerson]

That's definitely a valid piece of anecdotal evidence. I'm not sure I feel any differently about the topic, but it's good to know.