Numbering compiler error messages?

[Brad Anderson]

On Saturday, 29 March 2014 at 17:12:45 UTC, froglegs wrote:
> On Saturday, 29 March 2014 at 15:37:05 UTC, w0rp wrote:
>> I agree with Walter about error numbers being a bad idea. 
>> Especially when people prefer the numbers over a description. 
>> MySQL has really turned me off the idea of error numbers. When 
>> I get an error about MySQL syntax, the message actually reads 
>> like this.
>>
>> "Error near <snippet> <line number> <column number> ... <error 
>> number>"
>>
>> It never tells you what kind of syntax error you made, or 
>> *exactly* where it actually happened (The line and column 
>> numbers are misleading.). You just get a message "well it 
>> broke" and an error number which might as well be the result 
>> of a hash function. As a result, I hardly ever look up the 
>> error number, and I just make a guess as to what I did wrong. 
>> It's usually faster to guess.
>>
>> It's kind of like the effect bug IDs can have on commit 
>> messagses, which I mentioned in another thread. If you put 
>> some ID you can search for in a message, some people have a 
>> tendency to rely on the ID and forget about providing a 
>> descriptive message as well.
>>
>> I think a better approach is to just describe the error 
>> better. When I use DMD I get some pretty good results already 
>> for errors. We just need to patch messages which may be 
>> confusing at the moment into being more descriptive.
>
>   The way Visual C++ does it is that you get *both* and error
> number and an error message.  Having the error number is very
> useful for googling(yes the complete message will give you hits,
> but the # is more concise and turns up more hits), and for
> quickly referring to a given error.

Yeah, exactly. You wouldn't lose the short error descriptions.
That'd be absurd.