-
Notifications
You must be signed in to change notification settings - Fork 1.8k
impl Fn
, impl FnMut
, ... as inlay hint for closures
#12297
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
Comments
impl Fn
, impl FnMut
, ... as inlay hint for closures, which I think is a useful data and non trivial in first look. In current state IMO it make sense to enable this by default.impl Fn
, impl FnMut
, ... as inlay hint for closures
impl Fn
, impl FnMut
, ... as inlay hint for closuresimpl Fn
, impl FnMut
, ... as inlay hint for closures
While the idea itself is great, I feel it probably won't work well as type inlay hints though. They only apply to variables, but most closure expressions are directly passed in as function arguments. I guess we could create a new inlay hint type for it, but on second thought, since inlay hints are always displayed, I'm not sure this is the kind of information that needs to be always available like that. For example, type inlay hints are almost always useful. Rust has a relatively complicated type system, and without knowing the exact inferred type of the variables at a glance, the code can be hard to write or understand. Maybe I'm missing something regarding motivation and use cases, but from my personal experience, I rarely need to think anything about
(From grep.app: in libstd there're about 66 places that require The times where I have to think about I'm not saying that knowing this information is always unnecessary, just that it doesn't need to be always there as an inlay hint, unlike type hints and co. It can become quite verbose, e.g. showing hints for every closure in an iterator chain. An alternative could be, instead of inlay hints, showing this infomation only when hovering over the closure expression. But I can't seem to get it to work in some situations (it'd highlight the whole expression instead of the closure itself). |
I think what was meant here was to configurably render Regarding hover for inlays that only got implemented yesterday, before the hover would fall through triggering generic hover |
@andylizi I think everywhere we render a closure type (which currently is in inlay hints, including complex one like boxed closures, in hover of closure pipes (which is what you are suggesting), in hover of variables that bound a closure, ...) it would be better to show I agree that this is not something that we can't live with it, it is just a nice to have, not for satisfying callers bound, but because these are different classes of closures ( |
I would like to see
impl Fn
,impl FnMut
, ... as inlay hint for closures, which I think is a useful data and non trivial in first look. In current state IMO it make sense to enable this by default.Originally posted by @HKalbasi in #12263 (comment)
The text was updated successfully, but these errors were encountered: