On Friday, 28 March 2014 at 17:28:13 UTC, Brad Anderson wrote:
>
> Something like this: http://dpaste.dzfl.pl/f552c718e935 (which triggers a bug in DMD unfortunately and DMD couldn't use phobos anyway).

Done at runtime so it works at least: http://dpaste.dzfl.pl/d3aae13a039c

On Friday, 28 March 2014 at 17:28:13 UTC, Brad Anderson wrote:
> (which triggers a bug in DMD unfortunately and DMD couldn't use phobos anyway).

Already reported: https://d.puremagic.com/issues/show_bug.cgi?id=11535

On 3/28/2014 2:09 AM, bearophile wrote:
> 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.

As I've said, I've done this before. Those lists get just as out of date and unmaintained whether they are numbered or not.

On 3/28/2014 2:23 AM, monarch_dodra wrote:
> Well, I'm just throwing that out there.

I've thought many times that an error message should be a clickable link. But until console displays support clickable text, it's just a fantasy.

On Friday, 28 March 2014 at 18:09:00 UTC, Walter Bright wrote:
> On 3/28/2014 2:23 AM, monarch_dodra wrote:
>> Well, I'm just throwing that out there.
>
> I've thought many times that an error message should be a clickable link. But until console displays support clickable text, it's just a fantasy.

You could output a URL. Some terminals support magically turning URLs into links.

On 3/28/2014 2:05 AM, bearophile wrote:
> 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.

No, it doesn't. Really. Grep does a fantastic job of that.


> - Give some discipline, order and systematicness to the world of D errors/warnings.

Been there, done that, doesn't work.

The ID's also make error messages look just plain ugly, as well as causing premature line wrapping, further uglifying the display.

On 3/28/2014 2:37 AM, 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.

Completely worthless:

1. Programmers program in English. Yes, I've asked many international shops about this. They want error messages in English.

2. The internationalized messages are *terrible* because you need a person who is fluent in that language, and in compilers, to write them. That just doesn't work out too well in practice.

3. Every time you add/change an error message to the compiler, then you have to go back to (2) and try to deal with that. Never works, or you get crappy translations, meaning (1) the foreign programmers again prefer the English messages.

I.e. been there, done that. Translated messages are great for a lot of apps, but not for programming tools.


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

The IDE doesn't have to parse them. All it has to do is do a substring search. The IDE developer would have to provide the patterns to search for, but that isn't any harder than creating an indexed table.

On 3/28/2014 10:28 AM, Brad Anderson wrote:
> 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.

The quality of error messages is always a problem, but numbers won't fix that. (Been there, done that, too. Numbering doesn't clarify things.) What we have been doing is, when lousy messages are identified, a PR is often produced to improve it. That's how these things get better, one message at a time.

On Friday, 28 March 2014 at 18:28:17 UTC, Walter Bright wrote:
> On 3/28/2014 10:28 AM, Brad Anderson wrote:
>> 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.
>
> The quality of error messages is always a problem, but numbers won't fix that. (Been there, done that, too. Numbering doesn't clarify things.)

I think we'll just have to agree to disagree on that point. I've found VC++ error numbers invaluable whenever I confront a confusing error. There are often examples of what cause the error and how to fix it.

> What we have been doing is, when lousy messages are identified, a PR is often produced to improve it. That's how these things get better, one message at a time.

Yeah, that is true (even if error numbers were adopted).

The error message I've always hated the most is "does not match any function template declaration" but error numbers wouldn't help with that one because the error is obvious but what exactly caused it isn't. I kind of wrote out an idea for one way it could be improved awhile back (basically just reformatting the message so you can point an arrow at the failing template constraint).

http://forum.dlang.org/thread/mailman.240.1389276481.15871.digitalmars-d@puremagic.com?page=4#post-vpglmlxqhiipeyrjfwzx:40forum.dlang.org

It's dated though because CyberShadow has since added column numbers and using that would be prefered, I think. Just underlining failing template constraint would do wonders. Combined with colored output and deciphering this error message would be almost pleasant.

On Friday, 28 March 2014 at 18:24:21 UTC, Walter Bright wrote:
> The IDE doesn't have to parse them. All it has to do is do a substring search. The IDE developer would have to provide the patterns to search for, but that isn't any harder than creating an indexed table.

Error messages can and frequently are improved and thus are not usable by tools. Error codes remain constant and thus are usable by tools.

IDE support would also allow things like pressing F1 on an error in the error list to be taken to something like wiki/ERR005 which may show an explanation of the error or an example of how to fix it or such. I'm not sure how useful this particular use case is though.

In an ideal world errors would be able to be outputted (using a compiler flag) in a program readable way (i.e., JSON or the like, with a code representing the error and data for that particular error, such as { code: ERR003, description: "variable 'foo' is unused", variable: "foo", file: "foo.d", line: 32 }, then your IDE could offer to remove the variable for you immediately, as well as other nice things like that. But without tool support I feel error codes aren't too useful, and in order to provide enough context to make tools useful you'd have to parse the error message in the first place which immediately makes it not practical and defeats the benefit of error codes.