Numbering compiler error messages?

[Brad Anderson]

On Saturday, 29 March 2014 at 00:27:36 UTC, Martin Nowak wrote:
> On 03/28/2014 09:32 PM, Brad Anderson wrote:
>>>
>>> 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.
>
> Well, invest the time saved on maintaining numbers to improve 
> the error message thus making it less confusing.

I think those are two different problems though. Better error
messages are certainly a good thing that everyone agrees with.
Error numbers solve the problem of keeping error messages brief
while giving the user a way to lookup more information about it.

For example, in VC++ if you get "C2001 newline in constant" you
can just lookup C2001
http://msdn.microsoft.com/en-us/library/4x3c2e37.aspx and there
is a long description of exactly why this error occurs along with
examples of code that can cause the bug and code that fixes the
bug. You aren't going to include all of that in an error message.
Experienced programmers see "newline in constant" and immediately
know the mistake from experience but an new programmer might see
that and think it has something to do with the "const char*"
portion of the line. If you click around other errors in the MSDN
link you'll see they do this for pretty much every error.

I'm convinced it's not worth it for every error but for some of
the more confusing ones that require a longer explanation than
would fit on the command line comfortably it'd be nice to have
somewhere on the wiki that can be linked for people to read more
about it.