specify type of field when filling with todo!()

[rosefromthedead]

i.e. after "Fill struct fields", instead of

S { a: todo!() }

now we can do

S { a: todo!("provide HashMap<String, Option<usize>>") }

[bjorn3]

This makes it harder to remove the todo!() again.

[rosefromthedead]

Yeah, that's true for editors without things like c$ or helix's treesitter nav, but surely shift-end or a couple of ctrl-deletes isn't that bad? I could see it being a problem, but it's a matter of opinion whether it's worth it for the type hints. Alternatively, does/could r-a provide correct inlay type hints for struct fields with broken initialisers? I think that would solve this problem without affecting the todo!()s at all.

[bjorn3]

Alternatively, does/could r-a provide correct inlay type hints for struct fields with broken initialisers?

That could work I think. Alternatively there could be a setting to switch between the current and new todo!() placeholder.

[kpreid]

Alternatively there could be a setting to switch between the current and new todo!() placeholder.

There is already the setting rust-analyzer.assist.expressionFillDefault, which could gain a new value like todoWithType.

[rosefromthedead]

IMO there should be a new setting - someone wanting type hints might also want defaults where possible. Even in the default fill mode, todos are still emitted when r-a doesn't know a default.

[bors]

:umbrella: The latest upstream changes (presumably #12905) made this pull request unmergeable. Please resolve the merge conflicts.

[Veykril]

I'm sorry for not having merged this PR by now, but I was still contemplating whether having this is worth it or not, and I am inclined to say no after all.

Alternatively, does/could r-a provide correct inlay type hints for struct fields with broken initialisers? I think that would solve this problem without affecting the todo!()s at all.

But I like this, I think we could maybe do the following which would help out with the main issue you want to solve which is to annotate todo/unimplemented macro calls with an inlay hint showing the type that is expected? Bikeshed but something like todo!<String>()

[Veykril]

@kpreid what are your thoughts on my previous comment regarding the use of inlay hints instead? (Since you were the one who opened the issue)

[kpreid]

what are your thoughts on my previous comment regarding the use of inlay hints instead?

Hm. In principle it is elegant, but I don't think it would work very well for the situations I imagine.

1. As far as I know, you can't copy text out of an inlay hint, so I would have to retype any relevant type names.
2. I have inlay hints set to offUnlessPressed, which means I can't look at them when I'm typing but would have to alternate looking and typing. (This is because they're a lot of visual noise, especially on any of the stock light themes, and they stretch lines past their usual length, creating awkward formatting.)

I haven't recently had very many complex struct literals to deal with, though, so my hypotheticals may not be very refined.

[flodiebold]

I wonder if we could show signature help for struct literals. I think that plus better expected-type-based completions would help here.

[Veykril]

I wonder if we could show signature help for struct literals. I think that plus better expected-type-based completions would help here.

That sounds like a nice idea imo

[Veykril]

I am going to close this after all. I don't think rendering the types into a string in the todo is a good idea, we should instead look into rendering signature help for constructor literals and maybe also add the inlay hint idea.