My Little Dustmite: Bisect is Magic

[Ethan]

On Sunday, 28 July 2019 at 11:41:20 UTC, John Colvin wrote:
> In D it's very easy for one little typo to invalidate vast 
> amounts of code, which leads to massive cascading errors.

I mean, that's true of C++ as well.

> How would you propose changing the compiler such that you got 
> the "right" amount of errors, without any spurious ones? IIRC 
> the current design "poisons" anything derived from an error to 
> minimise error spam.

I've long held the view that DMD's error reporting is not that 
great. And after my recent poke at the C++ mangler code and 
seeing the state of things...

The move to DDMD means it's time to revist the reasons for why 
error reporting was done like that in the first place.

First and foremost, my constant battle for *any* error generated 
while processing code must show the file and line it was 
processing at the time. I know Walter's view is "you know what 
code you were just writing."

But the reality of software development in D (templates and 
mixins and metaprogramming, oh my!) and software development in 
general (pull a source code database from the internet and 
compile it with a newer version of a compiler than it was 
generated on) means that the point becomes increasingly 
irrelevant as time and complexity increases from when a piece of 
code was originally written.

My other battle is error codes. Microsoft's documentation is spot 
on there. Your compiler generates an error code. Copy that code 
and stick it in to Google. Microsoft results up top, 
StackOverflow/etc right beneath it. Now you can go directly to 
relevant articles instead of trying to strip all context out of 
the message like type names and Google things that way, which is 
really inconsistent in the results you can get.

The old argument that error codes increase the execution time of 
a compile, or the compilation time of DMD, surely must be 
irrelevant now. All this stuff can be handled with D's 
metaprogramming capabilities for no runtime cost. Don't make a 
table that needs static initialisation, make a table and assign 
it to an enum. The error function already works as a printf, so 
that's not a problem. You can even reduce the number of error 
calls you need to make, since the error code can contain 
information on whether it's a fatal error that stops the compiler 
or not. Currently that's two calls - one to error() and one to 
fatal().

And with all those error codes centralised, you can also generate 
documentation and upload it to dlang.org. Imagine the luxury of 
searching documentation instead of disparate forum posts for 
information on your error.

So with all this in place. static_assert is currently treated as 
a fatal(), right? But I don't want it to. But some people desire 
that behavior. So surely we can parameterise static_assert in 
some manner to allow this?