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
