why ; ?

[Michael Neumann]

Janice Caron wrote:
 > 2008/5/8 Nick Sabalausky <a at a.a>:
 >>  Not that I'm advocating any "non-compulsory semicolon" syntax, but 
couldn't
 >>  the first one work fine by saying "Newline and semicolon are BOTH
 >>  interpreted as end-of-statement"? (aside from the issue of "with or 
without
 >>  a continue-on-next-line symbol"). Or am I just taking the discusion 
in a
 >>  circle?
 >
 > Yeah, we're going round and round. If I break a line because it's too
 > long, I absolutely do not want the compiler assuming that means "end
 > of statement". As numerous examples have shown, it is perfectly
 > possible for the compiler to misinterpret the programmers intent, and
 > produce code that does completely the wrong thing.
 >
 > There are only two ways to avoid this problem:
 > (1) require semicolons at end of statement
 > (2) require line breaks which are not end-of-statement to be escaped

  (3) "Intelligent Parser"

     a +
     b

Here the parser knows that something has to follow.

     f(1, 2, 3,
       4, 5, 6)

Here again the parser knows that something has to follow.

Etc.

It works perfectly well in Ruby, and I've never found a bug according to
a wrongly placed newline during the last ~10 years writing some multiple
10k LoC in Ruby, while I often get nerved by the C/C++ compiler due to
missing semicolons.

Actually, IMHO any C-style syntax has much more sever problems leading
to hard to find bugs:

     if (a)
       s1;
     s2;

   vs.

     if (a)
     {
       s1;
       s2;
     }

   vs. in Ruby (Eiffel/Ada/Modula-style syntax)

     if a
       s1
       s2
     end


Another example which leads to hard to read code and potential
bugs is (ignoring compiler warnings):

     class A
     {
       int i;

       //
       // add some 25 lines of code here
       //

       void foo(int i)
       {
         // what is "i" here?
       }
     }

This is solved in Ruby by using a separate namespace for instance
variables ("@i" for instance variable "i", and "i" for local variable
"i"). I regard this as one of the most important features found in Ruby
to prevent such issues and increase readability (and no, "@" has nothing
to do with the "@" used by Perl :).

I wouldn't suggest to remove semicolons from D, as the syntax it uses
makes it somewhat harder than the syntax used by Ruby (Python etc.).
But I'd suggest to introduce @variable as a synonym to this.variable.

Regards,

   Michael