On 18/01/2022 11:46 AM, H. S. Teoh wrote:
>> clang-format is indeed something I very much miss for D. Precisely
>> this "only reformat this small fragment" functionality is extremely
>> time saving.
> Does dfmt not do this?

Doesn't appear to.

Keep in mind it uses libdparse to actually ya know, parse the code.

So a small fragment probably wouldn't format properly beyond some basic rules anyway.

On 18/01/2022 11:46 AM, H. S. Teoh wrote:
> Point.  I remember when I used to be more active on the Phobos PR queue,
> a sad amount of time was spent over formatting issues (the right amount
> ought to be zero. :-D).

I totally agree with this.

When it comes to PR's into a repo of any given size, they should all be run through a formatter automatically.

No exclusions, just automatic, either the output is right or needs to be sanified, or with local disabling of formatting.

On Monday, 17 January 2022 at 21:46:08 UTC, forkit wrote:
> So I use clang-format extensively...like all the time.
>
> It makes such a difference, I can't imagine programming without it anymore.
>
> But D doesn't have something integrated like this.
>
> I am aware of dfmt.. but even on it's github page it says "dfmt is beta quality."
>
> I wonder if it isn't time a code formatter for D became a more integrated product, into the release itself, so that people like me can actually rely on it to work as expected, and also, so that the formatter's needs were considered whenever making changes to D.
>
> Or is D code now so variable and complex, that no formatter can reliably format it?

You might want to have a go at sdfmt.

1/ clone https://github.com/snazzy-d/SDC
2/ Go in it and make -j bin/sdfmt
3/ bin/sdfmt -i myfile

It is very much work in progress, but uses an approach similar to clang format (contrary to dfmt which IMO uses an approach that doesn't lend itself to get the same level of quality).

You'll almost certainly run into weird stuff, and I'd be happy to hear about them so they can get ironed out.

On Tuesday, 18 January 2022 at 01:59:25 UTC, rikki cattermole wrote:
> On 18/01/2022 11:46 AM, H. S. Teoh wrote:
>>> clang-format is indeed something I very much miss for D. Precisely
>>> this "only reformat this small fragment" functionality is extremely
>>> time saving.
>> Does dfmt not do this?
>
> Doesn't appear to.
>
> Keep in mind it uses libdparse to actually ya know, parse the code.
>
> So a small fragment probably wouldn't format properly beyond some basic rules anyway.

This approach is fundamentally flawed, as keeping all the info you need through an AST is pretty much impossible.

Modern formatter, such as clang-format, use a parser, but the parser generates an IR that as nothing to do with the traditional AST you'd get out of a regular parser.

To get an idea of what these IR looks like: http://journal.stuffwithstuff.com/2015/09/08/the-hardest-program-ive-ever-written/

On 1/17/2022 6:06 PM, deadalnix wrote:
> Modern formatter, such as clang-format, use a parser, but the parser generates an IR that as nothing to do with the traditional AST you'd get out of a regular parser.

What comes to mind is what to do with the comments.

On Tue, Jan 18, 2022 at 01:46:58AM +0000, forkit via Digitalmars-d wrote: [...]
> Surely I am not the only one that declares a dynamic array initialised using a Result set?
> 
> Is this not allocated on the GC managed heap?

Of course it is.


> How has that been excluded from the original implementation considerations of -profile=gc

For historical reasons, I wager.  The earliest versions of D did not have templates nor ranges.  Neither was there @nogc.  And IIRC, there wasn't core.memory.GC either, or maybe it was there but not with the entire API that we have today, I'm not sure.  At any rate, at the point where -profile=gc was implemented I believe built-in constructs *were* the only constructs to GC-allocate.  So it worked well at that time.

Since then, many things have changed, and it looks like -profile=gc has bitrotted to its present sorry state.


> And more to the point, excluded from considering adding it to this feature, for 7 years now.
> 
> I don't get it.
[...]

The problem with programming language design is that the design space is exponential in the number of features. Every new feature added, every language changed introduced, produces a ripple effect that percolates throughout the language in exponentially-many combinations that are impossible to exhaustively test.  So it's pretty much inevitable that some combinations of features will be poorly-tested or not tested at all.

On top of that, most bugs occur around boundary cases, and generally people who have been using older versions of the language are less likely to encounter these boundary cases, because they have become habituated to older, well-worn idioms. So they're less likely to notice these corner cases. Newcomers tend to find them more easily, though, because they haven't acquired the old habits. (Which is another reason it's important to file bugs: old-timers are less likely to encounter these bugs again and fix them.)

That, and old-timers tend to know their way around better, and upon encountering problems would resort to workarounds, avoiding the problem feature, so the problems can linger.


None of this excuses the present sorry state of things, of course. My inclination is to pull the trigger on -profile and -profile=gc. Or at the very very least, put a big fat warning in flashing bold red letters in the docs of the latter so that newcomers don't fall for it.


T

-- 
Bomb technician: If I'm running, try to keep up.

On Tuesday, 18 January 2022 at 03:39:10 UTC, H. S. Teoh wrote:
>
> None of this excuses the present sorry state of things, of course. My inclination is to pull the trigger on -profile and -profile=gc. Or at the very very least, put a big fat warning in flashing bold red letters in the docs of the latter so that newcomers don't fall for it.
>
>
> T

../druntime/src/rt/profilegc.d

from:
 fprintf(fp, "bytes allocated, allocations, type, function, file:line\n");

to:
 char[] WARNING = "-profile=gc is presently in a sorry state. You should consider not even using it."
 fprintf(fp, "%s\nbytes allocated, allocations, type, function, file:line\n", WARNING);

On Tuesday, 18 January 2022 at 04:05:05 UTC, forkit wrote:
>
> ../druntime/src/rt/profilegc.d
>
> from:
>  fprintf(fp, "bytes allocated, allocations, type, function, file:line\n");
>
> to:
>  char[] WARNING = "-profile=gc is presently in a sorry state. You should consider not even using it."
>  fprintf(fp, "%s\nbytes allocated, allocations, type, function, file:line\n", WARNING);

oops...should be:

const char *WARNING = "-profile=gc is presently in a sorry state. You should consider not even using it.";
            fprintf(fp, "%s\nbytes allocated, allocations, type, function, file:line\n", WARNING);

On Mon, Jan 17, 2022 at 07:30:53PM -0800, Walter Bright via Digitalmars-d wrote:
> On 1/17/2022 6:06 PM, deadalnix wrote:
> > Modern formatter, such as clang-format, use a parser, but the parser generates an IR that as nothing to do with the traditional AST you'd get out of a regular parser.
> 
> What comes to mind is what to do with the comments.

They should be explicitly represented. Ignored by the part that deals with language grammar, but remain in place to be accounted for during formatting.


T

-- 
Verbing weirds language. -- Calvin (& Hobbes)

On Tuesday, 18 January 2022 at 02:06:01 UTC, deadalnix wrote:
>
> This approach is fundamentally flawed, as keeping all the info you need through an AST is pretty much impossible.

It is not impossible. Roslyn has a SyntaxTree build dynamically (on expand) which includes every character in the source code (as slices). This tree allows operations on source code as formatting or code refactoring.

In parallel, it has a SemanticModel tree which is built separately stripped of any irellevant information for the semantic analysis. This tree is used to emit CIL code or enabling features like edit and continue.

Both trees use as backstore a minimal AST (green nodes) which is dynamically regenerated and its nodes reused on any text change.