An idea stolen from C#:

How about adding a small 'error-message ID' like DPL00042 to every
compiler message? This makes it easier to search for information about
the error. If tools want to handle certain compiler errors then
they can grep for the message-ID instead of the complete message.

I thought of adding a wiki page, wiki.dlang.org/Compiler_Messages to keep a list of all messages. It's then possible to add examples, detailed information how to resolve an error and links to further information (e.g. changelog entry for error/warning/deprecated message) to that page.

I could file a pull request which does this for all existing error
messages, but it requires contributors to follow a small protocol
for future error messages as we need to make sure we do not assign one
ID to different messages:

If you want to introduce a new error message:
Before even opening a pull request,
* go to  wiki.dlang.org/Compiler_Messages
* pick next free ID
* add it to the page with status pending
* Once stuff is merged update the description/status on the wiki page

As an example how this could work, search for CS1002.
So do we want this?

On 3/28/2014 1:23 AM, Johannes Pfau wrote:
> As an example how this could work, search for CS1002.
> So do we want this?

I've done this before. Short answer, it's a pain and doesn't really help.

Searching is easy, just type in the message that was displayed, sans the variable part. I do it all the time.

Johannes Pfau:

> How about adding a small 'error-message ID' like DPL00042 to every compiler message? This makes it easier to search for information about the error.

I still think it's a good idea for D. It was proposed time ago.

It has two advantages:
- Make it easier to find info about an error. The info can explain the bug, show clear examples of the mistake, and how to fix it.
- Give some discipline, order and systematicness to the world of D errors/warnings.

Bye,
bearophile

Walter Bright:

> I've done this before. Short answer, it's a pain and doesn't really help.

Since last time we have discussed this topic I have a better answer:

It's a psychological thing: numbering things push people to count them and write down a piece of information (like a wiki page) for each number. Currently there is no complete dictionary of D errors/warnings/dips. This advantage alone seems enough to me to justify numbering them.

Bye,
bearophile

On Friday, 28 March 2014 at 09:04:00 UTC, Walter Bright wrote:
> On 3/28/2014 1:23 AM, Johannes Pfau wrote:
>> As an example how this could work, search for CS1002.
>> So do we want this?
>
> I've done this before. Short answer, it's a pain and doesn't really help.
>
> Searching is easy, just type in the message that was displayed, sans the variable part. I do it all the time.

I think we could maybe find a middle ground? Not every error needs numbering, but having the more common ones "named and tagged and explained" could always help?

I'm thinking things like:
- expression has no effect in...
- cannot default initialize...
- dangling else...
- empty if/for/while statement...

It would really benefit the newer users that hit the error, to have a direct link explaining how things work in regards to that.

It doesn't have to be a number. A simple (shortened) link to the wiki could also work. Or simply a formalized error name "Invalid default initialization Error: Custom error message here"

A good argument in favor of that is that *you* would merely add the link in the compiler, and the community could document and explain the error.

Well, I'm just throwing that out there.

On Friday, 28 March 2014 at 08:25:05 UTC, Johannes Pfau wrote:
> An idea stolen from C#:
>
> How about adding a small 'error-message ID' like DPL00042 to every
> compiler message? This makes it easier to search for information about
> the error. If tools want to handle certain compiler errors then
> they can grep for the message-ID instead of the complete message.
>
> I thought of adding a wiki page, wiki.dlang.org/Compiler_Messages to
> keep a list of all messages. It's then possible to add examples,
> detailed information how to resolve an error and links to further
> information (e.g. changelog entry for error/warning/deprecated message)
> to that page.
>
> I could file a pull request which does this for all existing error
> messages, but it requires contributors to follow a small protocol
> for future error messages as we need to make sure we do not assign one
> ID to different messages:
>
> If you want to introduce a new error message:
> Before even opening a pull request,
> * go to  wiki.dlang.org/Compiler_Messages
> * pick next free ID
> * add it to the page with status pending
> * Once stuff is merged update the description/status on the wiki page
>
> As an example how this could work, search for CS1002.
> So do we want this?

There's another advantage. If you want to change error message (or add localization like in visual c++) you still can found what the error means.

It should be easier for IDE to parse and give suggestions or redirect to an help page to solve the problem.

Walter Bright:

> I've done this before.

The ecosystem changes (internet, wikis, IDEs, appear), and programmers too change (many learn JavaScript as first language, etc). So what's important is if a feature is good today. Past experience is useful, but only up to a point.


> it's a pain

What is the pain caused by those numbers?

Bye,
bearophile

On Friday, 28 March 2014 at 09:37:52 UTC, Andrea Fontana wrote:
> There's another advantage. If you want to change error message (or add localization like in visual c++) you still can found what the error means.

This is the only decent reason given for numbering and, considering dmd's not localized yet, is far from being a need.  I'm all for putting better explanations of error messages somewhere online, but Walter's right that keyword search is a better interface these days and numbering is unnecessary overhead.

> It should be easier for IDE to parse and give suggestions or redirect to an help page to solve the problem.

If there are such help pages for error messages, there's basically no advantage to numbering over string matching for the error messages and an additional cost of keeping track of all the numbers.

On Friday, 28 March 2014 at 11:15:36 UTC, bearophile wrote:
> Walter Bright:
>
>> I've done this before.
>
> The ecosystem changes (internet, wikis, IDEs, appear), and programmers too change (many learn JavaScript as first language, etc). So what's important is if a feature is good today. Past experience is useful, but only up to a point.
>
>
>> it's a pain
>
> What is the pain caused by those numbers?
>
> Bye,
> bearophile

I think he's speaking about mantain the table with the errors messages and errors code and I did a program that used a similar approach. It was written in C so maping this values is too expansive and tedious.

Instead of

error("undefined variable %s", id->name);

you need to:

error(ERR_UNDEF_VAR, get_error_msg_string(ERR_UNDEF_VAR), ERR_UNDEF_VAR, id->name);

the error string should contains also error message itself but the formatting too. Formatting are used in functions which do accept a variadic arguments if you do some update in the string and forget to add respective argument or change the order of your enum member and it mismatch to error_msgs_strings table index you just will print garbage/wrong error message and or number/crash program.

const char *error_msgs_strings[] = {
  "error code: %d undefined variable %s",
  "...",
};

Also, I was using linear error codes in this example and you're not looking for this, isn't? I don't know much application which does somethng like this. In this case, a simple error_msgs_strings[ERR_UNDEF_VAR] will not work and you need to create a hashtable. To print a single error code you need to do a search now just like it does for every identifier in the program. It isn't too bad since compile errors aren't too often necessary to do like a search for a identifier in the string table. But it depending how large is your table of error messages and if you are using an approach that isn't exit in the first error message, it will make the edit-and-compile cycle too slow.

On Friday, 28 March 2014 at 08:25:05 UTC, Johannes Pfau wrote:
> An idea stolen from C#:
>
> How about adding a small 'error-message ID' like DPL00042 to every
> compiler message? This makes it easier to search for information about
> the error. If tools want to handle certain compiler errors then
> they can grep for the message-ID instead of the complete message.
>
> I thought of adding a wiki page, wiki.dlang.org/Compiler_Messages to
> keep a list of all messages. It's then possible to add examples,
> detailed information how to resolve an error and links to further
> information (e.g. changelog entry for error/warning/deprecated message)
> to that page.
>
> I could file a pull request which does this for all existing error
> messages, but it requires contributors to follow a small protocol
> for future error messages as we need to make sure we do not assign one
> ID to different messages:
>
> If you want to introduce a new error message:
> Before even opening a pull request,
> * go to  wiki.dlang.org/Compiler_Messages
> * pick next free ID
> * add it to the page with status pending
> * Once stuff is merged update the description/status on the wiki page
>
> As an example how this could work, search for CS1002.
> So do we want this?

I'm a big fan of CXXXX and LNKXXXX from Visual C++ personally but have never brought it up because I know Walter doesn't care for them. The quality of error messages in D is a weakness in my opinion though so anything to help with that is good in my book.

Thinking aloud here, maybe since DMD is switching to D instead of managing IDs they could just be a short hash of the base error message. Then a simple program could scan DMD's source and spot them all and print out a list which could be compared to the wiki list.

Something like this: http://dpaste.dzfl.pl/f552c718e935 (which triggers a bug in DMD unfortunately and DMD couldn't use phobos anyway).