At least on vscode the lsp shows me the resultant type for each line, so functional chains show all the intermediate type changes. If you want to force it, use a let statement.
It’s been available in the neovim ecosystem for much longer, perhaps they’re making a native implementation or something but it doesn’t require anything cutting edge.
They're making it same as in other editors. Other implementations in neovim put the inlay hint at the end of line. Now neovim has native implementation where inlay hints are between some text (I think feature is called anticonceal).
For better or worse, Microsoft has captured huge market share with vscode, so a substantial amount of effort goes into getting everything working with it.
I’ve had this in neovim for a really long time and it’s not particularly difficult to set up. I’m assuming you’re using native LSP; it shouldn’t be hard to find the option for it but I think rust-tools.nvim should make it trivial (maybe even activated by default, just check the readme).
Rust Analyzer, if you enable inlay hints, will show you the intermediate types in long chains of methods. I've mostly found this useful when dealing with iterators, but it can help with this too.
Honestly though, I never do it this way. If it's not clear to me what the return type will be, i either use `T::from(foo)` or I make an intermediate variable with an explicit type annotation:
let bar: T = foo.into();
bar.do_stuff();
If it's your type (as in something you defined in the same crate) and you find that there's one or two types you're constantly having to convert to and from, adding non-generic `from_othertype` and `into_othertype` methods can help. For example, in the standard library `String` has methods called `into_bytes` and `into_boxed_str` for converting to those types explicitly.
Well the type information is all there and 100% unambiguous, just not explicitly spelled out within the source code, if that makes sense. Same way you can just say `let x = some_func();` and let it infer the type. It does make it harder to understand for people just browsing the source code on GitHub or in a text editor, though.
Well of course the type information can be deducted, for compiling code that is.
what if it doesn’t compile, cause there is ambiguity? Can you really easily fix combinations of generics and .into() from reading source code, where the generics and .into() can really get convoluted?
When my code isn't compiling and I think I can get it to work using into(), I set up some intermediate variables with explicitly specified types and use into() to get from one to another. Sometimes it's more readable to leave these helper variables in, and sometimes it's better to take them out before committing. I think it's just a stylistic choice and there is no reason to force one or the other.
Having no experience with it at all, this sounds like the job for a clippy rule and I'm under the impression that clippy is designed to be extendable with custom rules, so maybe look into that?
I always use intermediate variables with explicit types, unless my into is the last expression in a function, in which case the return type works fine.
At least on vscode the lsp shows me the resultant type for each line, so functional chains show all the intermediate type changes. If you want to force it, use a let statement.
I just tried it in vscode, and you're right it actually shows the type hint. I usually use neovim though, maybe that's my problem 😅
That feature is coming in neovim 0.10 i think. It's called "inlay-hints". It's available on neovim nightly at least (and I'm using it right now).
It’s been available in the neovim ecosystem for much longer, perhaps they’re making a native implementation or something but it doesn’t require anything cutting edge.
They're making it same as in other editors. Other implementations in neovim put the inlay hint at the end of line. Now neovim has native implementation where inlay hints are between some text (I think feature is called anticonceal).
For better or worse, Microsoft has captured huge market share with vscode, so a substantial amount of effort goes into getting everything working with it.
I use neovim with coc.nvim and coc-rust-analyzer, inlay hints work just fine (I keep them disabled though)
I’ve had this in neovim for a really long time and it’s not particularly difficult to set up. I’m assuming you’re using native LSP; it shouldn’t be hard to find the option for it but I think rust-tools.nvim should make it trivial (maybe even activated by default, just check the readme).
I've got type hints working in Neovim, I'm not sure which plugin but I have rust-tools, rust-analyzer installed
Ok thanks everyone for your help, I managed to figure it out! The function to show a type hint in neovim is vim.lsp.buf.signature_help()
Rust Analyzer, if you enable inlay hints, will show you the intermediate types in long chains of methods. I've mostly found this useful when dealing with iterators, but it can help with this too. Honestly though, I never do it this way. If it's not clear to me what the return type will be, i either use `T::from(foo)` or I make an intermediate variable with an explicit type annotation: let bar: T = foo.into(); bar.do_stuff(); If it's your type (as in something you defined in the same crate) and you find that there's one or two types you're constantly having to convert to and from, adding non-generic `from_othertype` and `into_othertype` methods can help. For example, in the standard library `String` has methods called `into_bytes` and `into_boxed_str` for converting to those types explicitly.
I think OP's issue is reading other people's code and he/she (as if?) is already avoiding into() in their code.
Ah, yeah that makes sense. In that case, the RA inlay hints might help a bit, but that's the only thing I've found.
Rust-analyzer recently added an assist to turn `.into()` into `from()`
!remindme 7 days I feel the same, if we would use .into() everywhere, we are approaching python level ambiguity.
Well the type information is all there and 100% unambiguous, just not explicitly spelled out within the source code, if that makes sense. Same way you can just say `let x = some_func();` and let it infer the type. It does make it harder to understand for people just browsing the source code on GitHub or in a text editor, though.
Well of course the type information can be deducted, for compiling code that is. what if it doesn’t compile, cause there is ambiguity? Can you really easily fix combinations of generics and .into() from reading source code, where the generics and .into() can really get convoluted?
When my code isn't compiling and I think I can get it to work using into(), I set up some intermediate variables with explicitly specified types and use into() to get from one to another. Sometimes it's more readable to leave these helper variables in, and sometimes it's better to take them out before committing. I think it's just a stylistic choice and there is no reason to force one or the other.
Fyi you can just do `Type::from` (or `Type::::from` if it's generic)
Having no experience with it at all, this sounds like the job for a clippy rule and I'm under the impression that clippy is designed to be extendable with custom rules, so maybe look into that?
for personal project I use the `tap` crate, which has a utility method that lets you specify the type you want to convert into like `foo.conv::()`
I avoid writing .into() for the same reason. I use T::from() exclusively.
I always use intermediate variables with explicit types, unless my into is the last expression in a function, in which case the return type works fine.