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):
-
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. -
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. -
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.