On Wednesday, 17 August 2022 at 18:07:25 UTC, bachmeier wrote:

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.

On Thursday, 18 August 2022 at 02:30:50 UTC, zjh wrote:

Here is a link to the same content on Pastebin:

https://pastebin.com/qgGeT6bb

There are 3 files, separated with ----------.

On Thursday, 18 August 2022 at 11:18:29 UTC, Paul Backus wrote:

Thank you for sharing.

The only real problem I have with D tooling is that when I open large files, it slows to a crawl. I've never heard vscode max out my pc's fans before

On Wednesday, 17 August 2022 at 10:45:16 UTC, tastyminerals wrote:

I don't hang around this forum much anymore, but as luck would have it I took a peek today and saw this recent post.

I used to work on D tooling myself, precisely because I also thought it was not good enough, and unlike a good chunk of the D folks, I love having some fancy IDE do all kinds of things like context-sensitive auto-completion, project-wide symbol renaming, dynamic linting without having to compile anything...

In my opinion, there are 2 major issues, both of them have been touched upon in this thread I think.

One of them is the small community that doesn't mind the lack of advanced tooling, paired with a strong DIY mentality. Many people new to D probably faced this exact issue, they come and realize the tooling is subpar, then get told to work on it themselves if they want something better, and quickly move on to greener pastures.

The second is the language itself. D code is often littered with a lot of template-heavy code, which makes type inference difficult, and can thus cripple the capabilities of the editor as tons of variables have opaque types for which auto-completion and linting become impossible. The syntax itself had a few tricks up its sleeve as well IIRC, I remember relying sometimes on code conventions for my syntax highlighting.

I have no clue where serve-d is at currently, but back when I was working on D tooling, both it and my language server were using the same trio of DCD, D-Scanner and DFMT, which themselves had their own quirks as well, adding an extra layer of brittleness.

In order to go beyond their limits, at some point I tried experimenting with using DMD as a library, in the hope to get template resolution and such, however this wasn't easily done either, because DMD was never meant to be used inside of a language server. Firstly, it has a global state that doesn't play well with the nature of language servers (long-running processes, just like web servers). And secondly, it sometimes uses stdout, which is typically what language servers use communicate to editors, meaning DMD would have to be patched in order to be technically usable (without even thinking about how to then use its capabilities).

The last idea I had was to use tree-sitter [1] to make a server "from scratch", without using a tool for something it was not meant to be used for, and only using a parsing library. I never finished my tree-sitter syntax file for D though, some specific string syntaxes had to be done in code directly outside of the syntax file, and as I was working on another project, I gave up.

The problem of D's tooling is old, and will probably never be completely solved. As you said at the start of your post, this is hardly the first time this comes up. I predict it's also not going to be the last.

If I ever came back to D, I would probably try to use tree-sitter again to make some new D tooling: it is made specifically for parsing code at every keystroke in an editor while being embedded without any dependency. That's my conclusion for anyone crazy enough to dive into this...

[1] https://tree-sitter.github.io/tree-sitter/

On Monday, 22 August 2022 at 10:11:01 UTC, Laurent Tréguier wrote:

There is already a (WIP) grammar for D via tree-sitter https://github.com/CyberShadow/tree-sitter-d

Someone also wrote bindings for it(tree-sitter, not the grammar)

https://github.com/aminya/d-tree-sitter

On Monday, 22 August 2022 at 10:11:01 UTC, Laurent Tréguier wrote:

I don't think you can truly "solve" this problem in a language that has templates. Look at C++, it has much bigger tooling budget than D and still most IDEs have only rudimentary autocompletion that breaks as soon as any templates come into play. I think the issue is that you can even think of a solution that will work for a template, like array<int>, but in reality underneath that array<int> is a scary type of 10 or more templates nested together. The fact that many methods return auto type doesn't help either.

That said, when autocomplete works in D, it usually works better than comparable C++ autocomplete.