Improving Compiler Error Messages

[Nick Sabalausky]

"bearophile" <bearophileHUGS at lycos.com> wrote in message 
news:hrjhvk$pkk$1 at digitalmars.com...
>
> You have also to take into account the time wasted in D programming adding 
> semicolons when the compiler shows you errors caused by their absence :-)
>

Personally, I've never found the time spent adding semicolons, or fixing 
missing-semicolon errors, to be anything more than trivial.

>
> This code:
>
> return {
> JavaScript : "fantastic"
> };
>
>
> Is different from:
>
> return
> {
> JavaScript : "fantastic"
> };
>
>
> This is how JS reads that:
>
> return; // Semicolon inserted, believing the statement has finished. 
> Returns undefined
> { // Considered to be an anonymous block, doing nothing
> JavaScript : "fantastic"
> };// Semicolon interpreted as an empty dummy line and moved down
>

I find that example to count as a good argument against optional-semicolons. 
Sure, there may be ways around it, but the rules involved would be 
complicated, and also difficult to get just right.

>
> In a program most lines of code end at the newlines, so to reduce typing 
> and errors it's a good idea to swap the syntax: instead of adding an 
> explicit syntax to end lines (semicolon) it's better to introduce a line 
> continuation (like \ in Python).
>

I do a lot of line-juggling, so I've always found explicit line continuation 
operators to be a royal pain in the ass. In fact, the need for them is the 
primary reason I prefer not to use newline-based-end-of-statement languages. 
True, mandatory semicolons are something that affect the programmer *all* of 
the time, however, I've never once found those to be bothersome (except 
maybe as a newbie, many many years ago). Mandatory line-continuation 
operators, on the other hand, only affect me some of the time, but it's 
still fairly often, and it's a PITA every time. Your mileage may vary, of 
course.