Hover shows static type ("Never") for `throw` and `rethrow` but not types for "return" or "yield" about sdk

[DanTup]

This looks a bit odd, but I think it is working as intended. throw x is an expression, and the hover shows the static type of an expression (VS Code will highlight the whole expression when it shows the tooltip, not only the throw keyword).

In contrast, return and yield are statements and not expressions (you can write var a = throw '' but you can't write var a = return '').

While we could special case these, it might be odd to maintain a list of kinds of expressions that we don't want to show static types for. If we're going to change something, I wonder if it'd be better to instead specially handle return and yield/yield* to return the type of the expression they're returning/yielding.

@bwilkerson any thoughts?

[incendial]

@DanTup fyi

[userAdityaa]

Hey, We can build on hover type as the function return type. Whichever function is the try catch block inside must have some type of return type either void or data_types.

[bwilkerson]

I agree that it would be odd to treat throw differently than other expressions.

It isn't clear to me what value would be added by treating return, yield, and rethrow as expressions rather than as statements. On the other hand, I could see harm from treating statements as if they were expressions given that some users are going to be familiar with languages that have expressions in place of many of Dart's statements. I wouldn't, for example, want to treat if as if it were an expression and thereby mislead a user into thinking that it really is an expression.

Another possible solution here would be to revisit an earlier proposal to add some explanatory text when hovering over keywords. If that text makes clear the difference between statements and expressions then it would probably (a) remove the confusion in this case and (b) improve the ability of the tools to help users learn the language.

[incendial]

Then I assume this is working as intended. Should I close it?
I completely missed the idea of throw being an expression.

[lrhn]

It might be useful to see on a statement whether it has type void or Never, that is whether it can complete normally or not.
(But dead-code warnings for anthing after is probably good enough.)

[DanTup]

Another possible solution here would be to revisit an earlier proposal to add some explanatory text when hovering over keywords.

Yeah, I think that would be better and may give a way of including the type in something like return without it perhaps looking like an expression. The related issue is #50085 (which I think is currently missing some agreement on the best format/place to store the data).

[incendial]

Another possible solution here would be to revisit an earlier proposal to add some explanatory text when hovering over keywords.

That would be great. My pain point is the assert keyword as I always forget whether the second argument is a named argument or not. (but that's not related to this issue)