Adding D support to Clang format

[max haughton]

On Saturday, 29 April 2023 at 19:08:14 UTC, Zachary Yedidia wrote:
> On Saturday, 29 April 2023 at 10:46:45 UTC, Johan wrote:
>> On Saturday, 29 April 2023 at 10:08:41 UTC, Johan wrote:
>>> On Friday, 28 April 2023 at 23:30:37 UTC, Zachary Yedidia
>>>
>>> [...]
>>
>> I'm enthusiastic, but after some more thinking I think it's 
>> wise to talk with the sdfmt team and discuss which way to go: 
>> better to have everyone work on one project, rather than two. 
>> I'm very interested in working on a good formatter, but not 
>> two ;-)
>>
>> Perhaps the upsides of clang-format (what is already there) 
>> are not so large.
>> A big downside of clang-format is that you are tied to LLVM's 
>> project (release schedule, way of working, community, ...). In 
>> order to format D code, you'd have to install clang-format 
>> (and the whole LLVM dependency?). And you are programming in 
>> C++, which is a pity for a project that is purely for D.
>> Because sdfmt has its own 'parser' (excellent!), it is quite a 
>> small program that can easily be built using `dub`. That makes 
>> the barrier to entry for developers very small (no need to 
>> build or test `sdc` itself).
>>
>> -Johan
>
> I think you make some good points. The clang-format codebase is 
> a bit gnarly to work with (~20,000 lines of C++ without any 
> clear separation/organization for formatting all the various 
> languages). I wasn't aware of sdfmt until the foundation 
> meeting forum post yesterday, but maybe it is a better 
> direction to go in. Having briefly tried sdfmt, I think the 
> main thing I miss is comment/assignment alignment. I was under 
> the impression that this might be difficult to implement in 
> sdfmt, but if not I think that would resolve a lot for me 
> (sdfmt already does better than dfmt for me). It would also be 
> great to have import sorting.

Why is import sorting useful in practice? Anything more than ~3 
top level imports for me is a pretty big red flag for me - D has 
local imports, use them.

Wouldn't be hard to implement in theory, although keep in mind 
that sdfmt internally has no concept of an import other than in 
the "parser", so that might be more of an AST->AST type of thing 
(which are much, much, easier to implement if you have a 
formatter for the output).

> Some other minor issues with sdfmt are: not many configuration 
> options (though I found the defaults to be pretty good), no 
> documentation on how to set the configuration options that do 
> exist (i.e., the .sdfmt JSON file is not documented), and a 
> lack of visibility of the project overall because it is hidden 
> within SDC (probably why I was not aware of it until recently).
sdfmt not being particularly configurable is sort of by design.
> I think for now I'll just sit on my clang-format fork and see 
> if there is interest/it's feasible to implement these things in 
> sdfmt. If so, then I would be happy to use (and possibly 
> contribute to) sdfmt instead.

The sdfmt algorithm is basically a simplified take on the way 
clang format works as far as I'm aware, implementing the 
alignment stuff shouldn't be ridiculously hard although I'm not 
sure how clang format has it in their decision-making/heuristics.