Autocomplete for types with type constraints
See original GitHub issueProbably it hasn’t been implemented yet but I’ve decided to open the issue anyway.
Example:
fn main() {
println!("{:?}", foo()./* autocomplete here */);
}
fn foo() -> Result<i32, i32> {
Ok(42)
}
Autocomplete works for methods on impl<T, E> Result<T, E>
but doesn’t work on impl<T, E> Result<T, E> where E: Debug
and bunch of others with type constraints, i.e. doesn’t autocomplete unwrap
, expect
, etc.
Issue Analytics
- State:
- Created 6 years ago
- Comments:5 (4 by maintainers)
Top Results From Across the Web
Autocompletion broken for generic function parameter with ...
When you have a type which only consists of optional properties and use it in a generic context as a type parameter, the...
Read more >java - Autocomplete with generic types in concrete class of ...
When coding java in Ecipse (Kepler), I am having a problem when I am making a new variable of a generic interface type...
Read more >HTML attribute: autocomplete - MDN Web Docs
The HTML autocomplete attribute lets web developers specify what if any permission the user agent has to provide automated assistance in ...
Read more >How to get suggested types to constrained generic method
I would like autocomplete or intellisense or something to display B and C when I type AddName< seeing as how it is constrained...
Read more >Xcode Auto Complete Icons Descript… - Apple Developer
Hi. there are many areas in Xcode that have icons such as items in auto completion in code editor or the debugger at...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Hm, I wonder if we should be less conservative here and just resolve all methods regardless of trait bouds.
We’ll use trait bounds to disambiguate possible conflicts and (somewhere in the future), to annotate errors like “you are calling
.contains_key
onBTreeMap
, butKey
is notHash
. Add#[derive(Hash)]
?”@matklad I would prefer your idea. For example
At this point, intellij can’t know type constraints.