On Sunday, 24 October 2021 at 17:42:28 UTC, Gavin Ray wrote:

Genuine question: is it really so difficult to write such code "by hand"? I understand that language servers are convenient, but I find it almost impossible to imagine being completely unwilling or unable to write code without one.

I ask because I suspect most D users (including core contributors) regard this sort of tooling support as "nice to have," but not "essential", and therefore do not give a high priority to improving it. If it really is "essential" to a significant fraction of programmers, we might want to rethink that stance.

On Sunday, 24 October 2021 at 19:00:17 UTC, Paul Backus wrote:

I believe it's partly a problem of lazyness, e.g "I want to type less. I want to be proposed filter when I CTRL+SPACE after arr.fi ".

That case can be solved by doing a word split on the current document and by adding the results to the "good" completions when they are requested. If you have selective imports at the top of the module, for filter, map, each etc. then they are proposed as well.

The other part of the problem is that completion can be used to overcome the lack of knowledge of an API, for example. In this case the word split does not help.

On Sunday, 24 October 2021 at 19:47:10 UTC, Basile B. wrote:

Yeah, this is basically how Vim's built-in completion works. I sometimes use it to save typing on long identifiers, or to avoid spelling mistakes. But if I have to fall back to typing something out manually, it's not that big of a deal.

Maybe it's programmers who can't touch-type who rely heavily on tooling support? I know if I had to hunt-and-peck every letter of an identifier like formattedWrite, I'd be a lot more motivated to use code completion everywhere I could.

Yeah, in that situation having an easy way to view the docs is really helpful. I have a shortcut set up in Vim that opens the dpldocs.info search page with the identifier under the cursor, which works pretty well for the standard library and ok for dub packages, but a language server could probably do a better job.

On Wednesday, 20 October 2021 at 09:47:54 UTC, SealabJaster wrote:

//the type of the function depends on the type of the callback parameter
void func(__depend void function() a){
    a();
}

void func1()@nogc{
    func({printf("Hello, World!\n");});
}

void func2(){
    func({writeln("Hello, World!");});
}

On Sunday, 24 October 2021 at 20:04:05 UTC, Paul Backus wrote:

FWIW, I think it has less todo with being capable than being competitive. It is a lot easier to learn a new language or framework with high quality completion and precanned suggestions. This is becoming the standard for mature tooling, so it is only natural that more people will make it a prerequisite.

On Sunday, 24 October 2021 at 22:33:51 UTC, Ola Fosheim Grøstad wrote:

That explains why someone accustomed to mature tooling might choose to avoid D entirely. I do not think it explains the behavior described in this post by Gavin Ray, which is what I was responding to.

On Sunday, 24 October 2021 at 21:37:05 UTC, Menshikov wrote:

How about just adding a compile time parameter to @nogc?

void usesCallback(Func)(Func f) @nogc(isNoGc!Func){ f(); }

On Sunday, 24 October 2021 at 19:00:17 UTC, Paul Backus wrote:

Oh no, I do not have much issue with writing things by hand.
It's that using any post-fix/UFCS style function breaks the type-detection entirely.

Here's a recording to explain what I mean:

Imgur Video - Dlang Tooling Issues

So you see here that:

• The UCFS form of the same function used on a range gives no suggestions, documentations, etc
• The regular form gives on-hover docs, I can ctrl+click to go to it's definition
• Another problem which I didn't mention earlier: the state of D tooling allows you to pass the wrong types to functions. Here I pass string[] to a function which only takes int[] and the linter/lang server does not catch it. Only when I compile will a warning be showed.

Here's another good visual example with partition function:

• Trying to use UCFS to see which methods are available for my Range type, or to select the partition function I expect to see in the list to read the documentation

• Just using regular function calls

On Wednesday, 20 October 2021 at 09:47:54 UTC, SealabJaster wrote:

C++ concept constraints are placed in front of types. I think it is elegant and worth learning. e.g. fun(InputRange R,...)(...).

On Monday, 25 October 2021 at 02:17:13 UTC, zjh wrote:

Similarly, ... is also very comfortable to use. There is no need to expand the cycle manually.