libdparse was created at the time D frontend was written in a different language and wasn‘t available as a library.

The D frontend itself isn‘t allowed to adopt the latest D features straightaway, because it would make bootstrapping and porting to other compilers more complicated than it should be. So the frontend should be compilable with an older version of DMD. Furthermore it should be compatible with C++, so it can be used by GDC and LDC. Therefore DMD is not always pretty and might be not the best fit for the high level code and could profit from a high-level wrapper.

Can libdparse be such a wrapper? Updating libdparse would probably be less painful, because it doesn‘t need to reimplement the frontend.
Writing another "libdparse" is not desired because libdparse is used by such tools like D-Scanner and becomes actually useful if used by that tools.

It is a big change to libdparse, so I‘d like to know if something is wrong with it and if the work on it is welcome.

On Saturday, 27 April 2019 at 12:55:07 UTC, Eugene Wissner wrote:
> libdparse was created at the time D frontend was written in a different language and wasn‘t available as a library.
>
> The D frontend itself isn‘t allowed to adopt the latest D features straightaway, because it would make bootstrapping and porting to other compilers more complicated than it should be. So the frontend should be compilable with an older version of DMD. Furthermore it should be compatible with C++, so it can be used by GDC and LDC. Therefore DMD is not always pretty and might be not the best fit for the high level code and could profit from a high-level wrapper.
>
> Can libdparse be such a wrapper? Updating libdparse would probably be less painful, because it doesn‘t need to reimplement the frontend.
> Writing another "libdparse" is not desired because libdparse is used by such tools like D-Scanner and becomes actually useful if used by that tools.
>
> It is a big change to libdparse, so I‘d like to know if something is wrong with it and if the work on it is welcome.

I don't believe that this is possible.

  1. offical front end AST is different of dparse AST
  2. dparse uses special stuff for memory allocs

It's only possible in theory. I rather think that at some point a new tooling generation could hatch if DMD as a library becomes usable.

On Saturday, 27 April 2019 at 13:04:06 UTC, Basile B. wrote:
>   1. offical front end AST is different of dparse AST

isn't that just a matter of converting one representation into another one?

On Saturday, 27 April 2019 at 16:31:24 UTC, Eugene Wissner wrote:
> On Saturday, 27 April 2019 at 13:04:06 UTC, Basile B. wrote:
>>   1. offical front end AST is different of dparse AST
>
> isn't that just a matter of converting one representation into another one?

Virtually everything is just converting one representation in to another...

On Saturday, 27 April 2019 at 20:30:17 UTC, Amex wrote:
> On Saturday, 27 April 2019 at 16:31:24 UTC, Eugene Wissner wrote:
>> On Saturday, 27 April 2019 at 13:04:06 UTC, Basile B. wrote:
>>>   1. offical front end AST is different of dparse AST
>>
>> isn't that just a matter of converting one representation into another one?
>
> Virtually everything is just converting one representation in to another...

I mean it is a standard compiler task; also GCC takes AST of a frontend and translates it into another AST (I suppose GENERIC), it can optimize independent of the source language.