On Saturday, 27 July 2019 at 22:22:57 UTC, Ethan wrote:
> On Saturday, 27 July 2019 at 22:19:20 UTC, Bastiaan Veelo wrote:
>> If continuing is desired, would a `static if` combined with `pragma (msg, ...)` not be more appropriate than `static assert`? This can probably go into a ct function like `static_check`.
>>
>> Bastiaan.
>
> I was considering making that point myself. The static assert here is kinda useless, a pragma( msg ) won't stop compilation.
>
> This is in that weird <non-PC word> area that people keep bringing up. The recommended course of development with templates is to static assert with your own handy error message. The reality is that you lose vital information about why that template is not instantiating unless you litter your code with static ifs and pragma( msg )s.

Tossing in a `version` may produce a helpful idiom, if compilation should continue during lib dev and stop during lib usage:

```
import std;

void my_static_assert(alias condition, string message)()
{
    version(continue_past_assert)
    {
        static if (!condition)
            pragma(msg, message);
    } else {
        static assert(condition, message);
    }
}

void main()
{
    my_static_assert!(false, "fix your mistake");
    writeln("Hello D");
}
```

https://run.dlang.io/is/5NqYj7

On Saturday, 27 July 2019 at 16:59:36 UTC, Ethan wrote:
> On Saturday, 27 July 2019 at 16:36:35 UTC, Kagamin wrote:
>> Again, in this example the compiler does provide context that assert fails at line 11. Function bodies are compiled at a later stage and it doesn't make sense to compile them if top level declarations failed to compile
>
> Your definition of context is incomplete.
>
> I cannot think of a single programmer that wants to hit compile every time they fix one single compiler error just to find another single compile error.
>
> Stopping at one static assert is undesired behavior in a production environment.
>
> If this behavior is by design, it's terrible design.

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.

In D it's very easy for one little typo to invalidate vast amounts of code, which leads to massive cascading errors.

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?

On Monday, 29 July 2019 at 15:28:02 UTC, Ethan wrote:
> 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.

From C++20 overview https://hackaday.com/2019/07/30/c20-is-feature-complete-heres-what-changes-are-coming/ :
>As a result, the compiler can provide a short and meaningful error message if the defined requirement of a concept isn’t met, instead of dumping walls of errors and warnings from somewhere deep within the template code itself that won’t make much sense without digging further into that code.

Looks like C++ compilers are supposed to print less errors too.

On Wednesday, 31 July 2019 at 13:21:01 UTC, Kagamin wrote:
>>As a result, the compiler can provide a short and meaningful error message if the defined requirement of a concept isn’t met, instead of dumping walls of errors and warnings from somewhere deep within the template code itself that won’t make much sense without digging further into that code.
>
> Looks like C++ compilers are supposed to print less errors too.

Let's take a closer look, shall we....

>As a result, the compiler can provide a short and meaningful error message if the defined requirement of a concept isn’t met

>the compiler can provide a short and meaningful error message

>short and meaningful error message

>meaningful error message

Perhaps you missed the point where I'm complaining that the static assert behavior *HIDES* short meaningful error messages.

Come back to reality. We miss you.