D tooling is disappointing

[Alexandru Ermicioi]

On Wednesday, 17 August 2022 at 18:07:25 UTC, bachmeier wrote:
> The first step to improvement is being clear about what the 
> tooling should do. Then, importantly, reference tooling that 
> works for other languages and provide explicit information 
> about how to do that for D. Really, it doesn't help to talk 
> about "tooling". To push for change, you should pick the small 
> part of the tooling that is causing you the biggest headaches 
> and provide clear steps for improving that.

Well this list could be improved/implemented (note this may be 
obsolete since I haven't done much D programming recently):
1. Autocompletion
There is already a rudimentary autocompletion support in language 
server projects albeit rudimentary, due to the fact that the LSP 
cannot infer in all cases what kind of type is the field/variable 
from which you try to invoke a method, or access a field. So 
compiler would be a tremendous help here if it could infer the 
type of variable for which field/method autocompletion is done, 
considering that D usually is heavy on templates. Note that this 
inference should work on lambda heavy code as well.

2. Automatic import of symbol and import cleanup
It is really annoying when you need to manually write import 
statements to include a symbol from a module. It would be nice 
given some external knowledge (dub deps for example) that IDE 
would first autocomplete list of symbols you want to use, and 
when a symbol never imported prior to now is used, it will 
automatically import it (write an import statement for that 
symbol).
Cleanup part is useful when you don't use a symbol anymore and 
therefore it is not required to import it in respective scope.
No, `import std` is not a solution.

3. Refactoring utilities
- Interface implementation
There is already some rudimentary implementation, but not enough. 
 From what I remember these implementations were struggling a lot 
with classes that implemented templated interfaces.

- Symbol renaming
Same issue as others. No reliable way to rename a field/method in 
a class. You have always a chance to either rename more places 
than you need, or less than you need, resulting in a compilation 
error, or worse in accidental renaming of innocent variable in an 
irrelevant function (hello javascript).

- Member movement
More advanced use though. Mainly for static methods in 
structs/classes, and module level elements. You'd like to move a 
variable/method/function from one class/struct/module to another 
one, and expect that all uses of said subject to be rewritten to 
point to new struct/class/module that subject was moved to.

- Inlining of functions
Given a function/method, when inlining it, expect that all places 
where this method/function is invoked should be replaced with 
it's contents, adapted to the calling site.

- Code extraction
You have to manually extract now, interfaces, abstract classes, 
and object delegates (oop pattern).

Please note that these are general specifications of what each 
feature should do. It can be even more refined for D use cases.