https://github.com/Pure-D/code-d/issues/393

what do you think of this idea? worth checking out in the future? not important at all or high priority?

With hatf0 showing DMD-FE being able to run in WebAssembly I think this could be a very real possibility and we could be pretty close to it being doable already.

Instead of trying to port DCD could also try to immediately use DMD for auto completion, though that's a whole other project that would bring other benefits as well.

Other than syntax coloring for vscode-web i don't think having the full suite is necessary

I'd rather see more investment being made in improving DCD, there still lot of areas where it just is bad..

• auto data = cast(Data*) myPtr; this is basic code and yet DCD can't figure out what data is

• T get_x(T)(); auto x = get_x!float; DCD can't figure out it's a float

• const(int) myInt; DCD can't tell me it's a const

There are many more little things like that that just doesn't work

For a language that rely heavily on these features, it should be supported

And i don't think the D audience is using web based IDE, it's a system language

That would be a smarter time investment, getting basic things supported is long overdue

Because right now it's pretty rough compared to the competition (rust language server with analyzer)

We need retain people in the language, tooling is still rough decades later, that drives people away..

On Tuesday, 11 January 2022 at 12:29:25 UTC, WebFreak001 wrote:

Brute force solution is to just host some codeserver instances. I will do some at some point, for trying out new pull requests etc

On Wednesday, 12 January 2022 at 00:08:02 UTC, russhy wrote:

What's stopping you from working on it?

I agree, I wouldn't be using it myself, though it would be a cool way to try out the language online, and it would be a cool demonstration of D being capable of targeting WebAssembly.

On Wednesday, 12 January 2022 at 09:09:32 UTC, Dennis wrote:

well russhy did plenty of improvements to DCD, I think it's mostly nobody reviewing them or having time for it is delaying the contributions quite a bit.

I think it would be best to focus on making a DMD frontend based DCD replacement though.

On Wednesday, 12 January 2022 at 09:38:28 UTC, WebFreak001 wrote:

That's great to hear! Btw, russhy, sorry for the implication that you weren't working on it. I'm genuinely curious what the barrier is for D users to implement the DCD features they want (I haven't looked much at the code myself).

That's unfortunate. I started watching GitHub activity on the pinned dlang-community repos, intending to get more involved there.

On Wednesday, 12 January 2022 at 10:02:10 UTC, Dennis wrote:

it's ok, i'd have said the same if someone kept getting negative, but i'm trying to do better

the main issue is the project is way too scattered away

• dsymbol
• libdparse
• dcd
• containers
• allocators

everything has its own git repo, every project reference some random version from each other

it makes implementing fix/feature that touches many repo at the same time a pain to manage, and also i guess a pain for reviewers

i suggest the following:

• merge everything as a single entity in a single repo, and get rid of dependencies we don't need (containers? we have std, allocators? when will that get out of experimental?)

that'll be a start making the project easier to use and to understand! contributor friendly!