Is anyone working on a D source code formatting tool?

qznc via Digitalmars-d digitalmars-d at puremagic.com
Mon Jan 12 07:30:41 PST 2015


On Monday, 12 January 2015 at 05:43:33 UTC, Zach the Mystic wrote:
> On Monday, 12 January 2015 at 00:38:20 UTC, Walter Bright wrote:
>>>>> On 1/11/15 10:48 AM, Walter Bright wrote:
>>>>>> The main problem is what to do about comments, which don't 
>>>>>> fit into the
>>>>>> grammar.
>>>>> In the first version comments might go through unchanged.
>>>>
>>>> Consider:
>>>>
>>>>    for /*comment*/ (a;
>>>>                     b;
>>>>                     c)
>>>>
>>>> Do what with that?
>>>
>>> I don't know. Simplest would be to punt for now - such rare 
>>> embedded comments
>>> should not be blockers. -- Andrei
>>
>> Normally I would agree, but deleting peoples' comments from 
>> their source code is not a good plan. It'll make them 
>> justifiably angry.
>
> This conversation reminds me of something I've thought about 
> ever since I first studied D. D takes the C preprocessor and 
> folds it into the regular AST. But comments still seemed like 
> the outlier. I looked through a bunch of source code and tried 
> to figure out the most specific place anyone could possibly put 
> a comment. The most detailed I found were something like:
>
> enum X {
>   ONE,
>   TWO, // We need a TWO here
>   THREE
> }
>
> So I started conceiving of a language in which even the 
> *comments* were part of the AST. For, me this would be the 
> aesthetic ideal. It just seemed like the next step in total AST 
> integration.

The clang-format approach is to make decisions based on the AST,
but edit the byte array. AST nodes contain exact positions: line
and column numbers. Sometimes more of them. For example, an
if-statement needs to know the position of 'else' as well.

Here is another example: void setX(int position /* inches */);
However, I think it should really be wrapped into a struct
instead to get type checker's approval.

Initially, clang-format only did whitespace changes. I am not
sure if they weakened this already. For example, stripping parens
in expressions (((((x)))) => x) would be acceptable for me.


btw +1 for https://github.com/Hackerpilot/dfmt


More information about the Digitalmars-d mailing list